At Mon, 23 May 2011 14:51:19 -0400, Neil Van Dyke wrote: > The first PLT internals question I expect to look into is whether, in > the stack tace, "require"s are still being processed (by which I mean > evaluation has not yet proceeded into the non-"require" body of the main > Scheme file).
Yes. It looks like evaluation is four `require's deep (not counting the original module). By looking at `menv->module->name' in frame 353, you might be able to tell which module is being run. The crash at GC_clear_stack_segment() looks to me like the GC's idea of the stack range has gone bad, since the `limit' argument is reported out of bounds by gdb. I imagine the immediate crash is a result of running out of stack space while trying to grow the stack too far. The stack trace reminds me of a potentially relevant bug that was fixed in July 2010. See commit 816f66f4c5bfb69be913 and its changes to "jit.c". That commit fixes an x86_64-specific bug in handling cached stack-trace information. The bug would show up, for example, if an exception was raised and caught. If I remember correctly, the effect of the bug was to corrupt a callee-preserved register on the return from a frame where stack-trace information was cached. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
