exception from inside false-if-exception?

[Attila Lendvai <attila@lendvai.name>]

dear fellow Guilers,

context:
--------

i'm working on shepherd (with several non-trivial local commits). its test suite runs clean from a shell, but fails when i try to `./pre-inst-env guix build -K shepherd@0.10.99-git`.


the sympthom:
-------------

COLUMNS is not set in the guix build env, and the basic.sh test fails with the following exception/backtrace in the test log:

[...]
In ice-9/boot-9.scm:
  1747:15  8 (with-exception-handler [...])
In shepherd/support.scm:
    613:9  7 (_ . _)
In unknown file:
           6 (display-backtrace [...])
In system/repl/debug.scm:
   148:36  5 (print-frames [...])
In ice-9/boot-9.scm:
   2137:6  4 (_)
  1747:15  3 (with-exception-handler [...])
In system/repl/debug.scm:
    72:40  2 (_)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1683:16  0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
In procedure string->number: Wrong type argument in position 1 (expecting string): #f

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

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

if i paste this into a guile repl, then it behaves as expected.

i have verified that if i set COLUMNS in the basic.sh test, even if i set it to:

COLUMNS=""
export COLUMNS

then the guix package builds fine.

if i add:

unset COLUMNS

to the basic.sh test, then it makes it fail even in my dev shell (after a couple of minutes long timeout):

`make check TESTS="tests/basic.sh"`

there are no WITH-THROW-HANDLER's involved.


my question:
------------

unless i missed something, i seem to be getting an exception *from inside* a false-if-exception? how can that happen?

do i miss something, or is this a guile bug?

if this seems to be a guile bug, then i'll try to set up a simpler reproducer than my current one. in that case, what may be the key difference between the repl and the shepherd test suite? simply compiled vs. evaluated code?


a hypothesis:
-------------

i tried to look around guile's codebase, and STRING->NUMBER seems to be an optimized or otherwise specially treated primitive.

maybe that special treatment interferes with exceptions? maybe it throws a kind of exception that false-if-exception doesn't catch? or in a way that doesn't get caught?

this call of STRING->NUMBER is within the bootstrapped part of guile itself, which again may add an extra layer complexity or special teatment?

note that if i unset the env var then STRING->NUMBER is called with #f instead of an empty string. maybe there's a bug in how STRING->NUMBER handles being called with a non-string?

i didn't notice anything obviously wrong around SCM_VALIDATE_STRING.

any hint is appreciated,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Watch your thoughts; they become words. Watch your words; they become actions. Watch your actions; they become habit. Watch your habits; they become character. Watch your character; it becomes your destiny.”
	— Lao Tzu (sixth century BC)