[racket] debugging core dump - comments appreciated

Matthew Flatt wrote at 05/23/2011 09:52 PM:
> Looking more at GC_clear_stack_segment(), it doesn't allocate nearly
> enough stack space to run out with only 10 or so calls, at least not
> for a normal-sized stack. Is a stack limit set when running the Racket
> program?
>   

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?

What I was about to send in response to your previous email...

Thanks for the educational reading of the stack trace.

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?

(Sleepily, I'm wondering whether a billion invocations of a program that 
does little but "require" "char-set.ss" would also trigger the rare 
crash we are seeing.  I would be very surprised, but it would be like 
winning the lottery jackpot of minimal test cases, compared to debugging 
the large app.)

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