[racket] debugging core dump - comments appreciated

Matthew Flatt wrote at 05/23/2011 10:11 PM:
> At Mon, 23 May 2011 22:01:31 -0400, Neil Van Dyke wrote:
>   
>> We're not explicitly setting any stack limits anywhere.  I believe but 
>> am not certain that that core dump came from a "mzscheme -jqr" from 
>> inside an Apache CGI context that got a native stack ulimit of 8192 kB 
>> (the normal limit on that machine).  Shall I confirm this?
>>     
>
> Maybe, but I've become more interested in the possibility that other OS
> threads might have crashed. Does `info threads' work in gdb with a core
> file?
>   

I'm not certain "gdb" is accurate here, but I don't think that any C 
code we use introduces any additional OS threads.

#0  0x00000000005655b6 in GC_clear_stack_inner (arg=0x0, 
limit=0x7fff2dd5ce30 <Address 0x7fff2dd5ce30 out of bounds>) at ./misc.c:243
243    ./misc.c: No such file or directory.
    in ./misc.c
(gdb) info threads
  2 process 28526  0x00007fff316fcbe1 in nanosleep () from /lib/libc.so.6
* 1 process 28525  0x00000000005655b6 in GC_clear_stack_inner (arg=0x0, 
limit=0x7fff2dd5ce30 <Address 0x7fff2dd5ce30 out of bounds>) at ./misc.c:243


>> Could code evaluated at module load time, such as "make-standard-set" 
>> (which has some non-tail calls in loops, I don't know the size), be 
>> using lots of stack, and, once every 100,000 runs of a large program, 
>> combines with nondeterministic GC behavior and a bug to cause a seg fault?
>>     
>
> It seems unlikely that any module is using lots of C stack relative to
> 8MB, so I think we must be missing something simpler. Nondeterministic
> GC behavior seems like a likely part of the puzzle, though.
>   

(I'm not sure whether we're talking about a Scheme stack that is 
different than the native stack) Could we be having an overly large 
stack quite often, and the rareness of the crash is only because usually 
the stack does not collide with non-stack memory in a detectable way?

-- 
http://www.neilvandyke.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110523/c65db53a/attachment.html>