unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Andrew Whatson <whatson@gmail.com>, guile-devel@gnu.org
Subject: Re: [DRAFT] Improve reporting of exception locations
Date: Wed, 12 Oct 2022 21:16:10 +0200	[thread overview]
Message-ID: <ebf0e6c5-de9a-6c74-6415-2d6f051e5432@telenet.be> (raw)
In-Reply-To: <CAPE069f6e1n3+HTLfbNjy7P7FoqFZiG1n5s9QfMu+cFywjgMBQ@mail.gmail.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 2755 bytes --]



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.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

      parent reply	other threads:[~2022-10-12 19:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12  6:35 [DRAFT] Improve reporting of exception locations Andrew Whatson
2022-10-12  6:42 ` Andrew Whatson
2022-10-12 19:16 ` Maxime Devos [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ebf0e6c5-de9a-6c74-6415-2d6f051e5432@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-devel@gnu.org \
    --cc=whatson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).