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? > 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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
