GNU bug report logs - #46009
(backtrace) crash, string->number: Wrong type argument in position 1 (expecting string): #f

Previous Next

To reply to this bug, email your comments to 46009 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guile <at> gnu.org
Subject: (backtrace) crash, string->number: Wrong type argument in position
 1 (expecting string): #f
Date: Wed, 20 Jan 2021 22:46:38 +0000

[Message part 1 (text/plain, inline)]

It seems that with-exception-handler might be breaking
false-if-exception inside terminal-width from (system repl debug).

I've come across this when trying to use with-exception-handler to print
backtraces for exceptions.


→ cat backtrace-crash.scm

(peek "COLUMNS" (getenv "COLUMNS"))

(with-exception-handler
    (lambda (exn)
      (backtrace))
  (lambda ()
    (+ 1 a)))


→ echo $COLUMNS
84


→ guile --no-auto-compile backtrace-crash.scm

;;; ("COLUMNS" #f)

Backtrace:
Backtrace:
          10 (primitive-load "/home/chris/Projects/Guix/guix-build-c…")
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/eval.scm:
    159:9  8 (_ _)
   223:20  7 (proc #(#(#<directory (guile-user) 7f32e7dfbc80>)))
In unknown file:
           6 (%resolve-variable (7 . a) #<directory (guile-user) 7f3…>)
In ice-9/boot-9.scm:
  1669:16  5 (raise-exception _ #:continuable? _)
In unknown file:
           4 (backtrace #<undefined>)
In system/repl/debug.scm:
   148:36  3 (print-frames #(#<frame 7f32e6a22f30 backtrace> #<f…> …) …)
    72:20  2 (_)
In ice-9/boot-9.scm:
  1731:15  1 (with-exception-handler #<procedure 7f32e7e937b0 at ic…> …)
In system/repl/debug.scm:
    72:40  0 (_)

system/repl/debug.scm:72:40: In procedure string->number: Wrong type argument in position 1 (expecting string): #f

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 46009 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Attila Lendvai <attila <at> lendvai.name>, 
 "guile-devel <at> gnu.org" <guile-devel <at> gnu.org>, 
 "46009 <at> debbugs.gnu.org" <46009 <at> debbugs.gnu.org>, 
 Christopher Baines <mail <at> cbaines.net>, Andy Wingo <wingo <at> pobox.com>
Subject: RE: exception from inside false-if-exception?
Date: Mon, 29 Apr 2024 16:13:22 +0200

[Message part 1 (text/plain, inline)]

[Adding Andy Wingo because of the stack shenanigans]

>Subject: exception from inside false-if-exception?

Duplicate of #46009 - (backtrace) crash, string->number: Wrong type argument in position 1 (expecting string): #f - GNU bug report logs

>the expression pointed to by debug.scm,72:40 is this:

>(false-if-exception (string->number (getenv "COLUMNS")))

All uses of false-if-exception are wrong – I haven’t found a single exception (pun intended) to this rule so far.  It shouldn’t be treating stack overflows, out-of-memory, exceptions from asyncs, EPERM, etc., as #false.  – false-if-exception delenda est

[...]

What I think is going on here, is that the exception catching API is a bit of mess, and to a degree, non-composable, leading to bugs like this.

1. raise/raise-continuable + guard: perfectly composable, no problems.
2. throw + catch: that’s fine too, it’s just a historical Guile API for (1), albeit slightly less general. 
3. with-exception-handler – a procedural variant of the ‘guard’ macro – sure ok. Also good for continuable exceptions, IIUC.
4. Pre-unwind handlers / with-throw-handler. / ???.

This is the non-composable stuff (or, difficult to understand and compose, at least). If you are catching an exception to _handle_ it (say, in this case, with false-if-exception), then any throw handler/pre-unwind handler/whatever has no business whatsoever to interfere, and neither to even know something is happening in the first place.

Yet, the documentation says it “is used to be able to intercept an exception that is being thrown before the stack is unwound” – which it has no business of doing in the first place (non-composable). 

Also the description of pre-unwind handlers / with-throw-handler is rather low-level (it’s more described in terms of (un)winding rather than nesting) and it appears to have been grown a bit .. organically, I think it’s time for it to be replaced by a new design that’s (conceptually) closer to raise/guard/...

I suspect the problem is that these throw handlers or whatever are messing things up – whether because they are hard to use, impossible to use correctly or because they are incorrectly implemented in Guile and would propose them to be replaced by something else.

On this something else: according to the documentation, these throw handlers can be used for:

1. Clean up some related state
2. Print a backtrace
3. Pass information about the exception to a debugger

1: IIUC, this is what (dynamic-wind #false thunk clean-up-stuff) is for – this is not entirely correct w.r.t. userspace threading implementation, but can be salvaged with something like

>https://github.com/wingo/fibers/blob/7e29729db7c023c346bc88c859405c978131f27a/fibers/scheduler.scm#L278

to override ‘dynamic-wind’ (actually I think the API ‘rewinding-for-scheduling?’ would need to be adjusted a bit to allow for situations like implementing threads inside threads inside threads inside ..., but it should give the basic idea.)

2. the rationale for this reason, is that when an exception is caught (think ‘catch’ handler), we are not in the same dynamic environment anymore, so by then it’s too late to generate a backtrace. But we can have a cake(= have a backtrace) and eat it too(= post-unwind / in the catch handler), by using ‘with-exception-handler’ with ‘#:unwind? #false’.

That’s not entirely sufficient, because sometimes the exception was already caught and ‘wapped’ to give some extra context in the exception object (but losing some backtrace in the process). OTOH, this ‘losing some backtrace’ already happens in the current implementation IIUC, so it wouldn’t be worse than the current implementation in this respect. I think there is a solution that isn’t just “always record the backtrace and put it in the exception” (which would be terribly inefficient in situation you mentioned), but I haven’t found it yet.

Perhaps the (full) current continuation (think call/cc) could be saved? And then later, when ultimately a backtrace is to be printed, the stack of this continuation can be investigated – This might seem even more inefficient than saving a backtrace, but if you think about it, all those frames were already allocated, so you don’t need to allocate new memory or do much CPU things beyond saving some pointers, you just need to start some new memory branching of an earlier point in the dynamic environment/the frames when/after rewinding.  I’m thinking of spaghetti and cactus stacks.   (The benefit beyond ‘just include backtrace’ is: (1) almost 0 time/memory cost when not used (2) if desired, you can print _more_ information than just the backtrace, e.g. values of certain parameters or whatever.)

And after the backtrace or whatever has been printed, there is no reference to the call/cc thing anymore so it can be garbage collected(*).

(*) there is a bit of a caveat here with respect to user-level threading and pausing computations, where some stuff low(high?) on the stack might be saved for too long, so perhaps it would instead be better to save a delimited continuation – the exception handler that does the backtracing could then set some parameter with a tag that delimits where to stop the delimited continuation – for a comparison: I think there is a procedure with a name like “call-with-stack” or something close to that which does something like that.

(Also, the section “Exceptions” isn’t mentioning ‘raise + guard’, instead there is a separate R6RS section isolated from the rest of the manual – it treats historical Guile idiosyncrasies as the norm and standard SRFI / RnRS as an aberration. But that’s a different thing.)

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.