Hi, I've been studying the backtrace provided by Ludovic, trying to determine where, in the Scheme code, this error happened in thread 1.
l...@gnu.org (Ludovic Courtès) writes: > Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)): > #0 0x00007f7019db0d79 in scm_is_pair (x=<error reading variable: ERROR: > Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159 > #1 scm_ilength (sx=<optimized out>) at list.c:190 > #2 0x00007f7019e0e2f6 in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, > registers=0x0, resume=16) at vm-engine.c:909 > #3 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1555fe0>, > argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257 > #4 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1555fe0>) at > eval.c:481 > #5 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program > 1555fe0>) at async.c:400 > #6 0x00007f7019e0e17d in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, > registers=0x0, resume=16) at vm-engine.c:784 > #7 0x00007f7019e117da in scm_call_n (proc=#<program 13717c0>, > argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257 > #8 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481 > #9 0x00007f7019dff496 in really_launch (d=0x149e520) at threads.c:794 The call to 'scm_call_with_unblocked_asyncs' in frame #5 is an important clue, because it is used in very few places. I see only two such places in Guile (and none in Guix): https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/scm-style-repl.scm?h=v2.2.3#n80 https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n158 I assume that it must be the second one in this case. So, I believe frames 5-9 correspond to lines 147 through 158 of ice-9/threads.scm: https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n147 which is within 'call-with-new-thread', called via the 'begin-thread' macro used by 'n-par-for-each', here: https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n320 However, I would expect to see a 'catch' frame deeper in the stack, since the procedure passed to 'n-par-for-each' by graft.scm is wrapped by 'exit-on-exception'. >From these facts, I believe we can conclude that the error is happening within the body of 'begin-thread' in 'n-par-for-each', but outside of the body of 'proc' passed to 'n-par-for-each'. There's not a lot of code in there. My best guess at the moment is that this error is happening within the (apply proc args) on line 335, although I do not yet have an explanation of how that could happen. To be continued... Mark
