On 12-10-2022 08:35, Andrew Whatson wrote:
Hello guile-dev! I'm working on a revised patch to improve the reporting of exception locations, after last month's initial flawed attempt. The new patch takes the more radical approach of capturing the stack when an exception is created,
AFAICT, it only does for 'throw', not for things like(raise-exception (condition ...)) even though IMHO the latter is recommended.
including it as part of the compound exception object. This should ensure that we capture a correctly trimmed stack, while avoiding the complexities of pre-unwind handlers. This is similar to other dynamic languages where it's common to bundle stack info with exception objects. This approach will probably have a negative impact on code which is sensitive to the performance of exception creation; capturing the stack is more expensive than NOT capturing it. Is this something that we need to be concerned about?
I'd say, yes, though the only way to be sure is to have some software doing lots of raise-exception and comparing performance before and after. If raise-exception + guard or equivalent is slow, this prevents raise-exception from being used in contexts where lots of raise-exception can happen.
For example, I am writing a Guile library GNUnet-Scheme that handles messages coming from the network. For that, raise-exception + guard is potentially useful (*).
These messages are expected to be usually valid, but some malicious or otherwise broken entity could send malformed messages. Catching the stack is, as I understand it, slow, so this could aid a (intentional or unintentional) DOS attack.
Even worse, when processing recursive data structures, the length of the stack can be linear in the depth of the data structure (e.g. when using procedures like 'map'), potentially making things worse than in other languages' implementations.
(*) I actually seemed to have (mostly accidentally) avoided raise-exception so far because lots of code is a little CPS-y or using code like (if (valid? ...) (begin (foo ...) (continue (decode ...))) (stop), but I could easily have chosen for exceptions instead as they are supposed to be reasonably fast (due to being based on continuations and because they don't capture the stack (except when actually being printed)).
On the tests: according to the documentation, stacks have a limited lifetime, could you verify it works correctly (maybe do some 'call-with-prompt' around the exception handler that prints the message and 'abort-to-prompt' inside?) . If it isn't done already, could you verify that 'start-stack' still works?
Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
