[racket] debugging core dump - comments appreciated

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Mon May 23 22:11:29 EDT 2011

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

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

Posted on the users mailing list.