[racket] debugging core dump - comments appreciated

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.