[racket] debugging core dump - comments appreciated

Matthew Flatt wrote at 05/23/2011 05:19 PM:
> At Mon, 23 May 2011 14:51:19 -0400, Neil Van Dyke wrote:
>   
>> is whether, in the stack tace, "require"s are still being processed

> 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.
>   

Thanks.  I will check this out as soon as I regain access.

> 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.
>   

Looks like that bug fix was after 4.2.5, and indeed we are on x86_64.  
However, we happened to have JIT disabled for the stress-testing that 
caused the core dump.  Two questions:

1. Would that bug you mentioned (or perhaps a very similar bug elsewhere 
in the code) affect us if JIT were disabled?  Or is that code only 
called if JIT is enabled?

2. In general, if we have JIT disabled, are we ever running code paths 
that no one else does, because everyone else uses JIT?  (Or, similarly, 
is it reasonably possible that we would encounter bugs that no one else 
does because everyone is running the probematic code but the JIT is 
mitigating somehow and avoiding the error condition?)

-- 
http://www.neilvandyke.org/