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)