<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Matthew Flatt wrote at 05/23/2011 10:11 PM:
<blockquote cite="mid:20110524021131.724406500B9@mail-svr1.cs.utah.edu"
type="cite">
<pre wrap="">At Mon, 23 May 2011 22:01:31 -0400, Neil Van Dyke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
</blockquote>
<br>
I'm not certain "gdb" is accurate here, but I don't think that any C
code we use introduces any additional OS threads.<br>
<br>
#0 0x00000000005655b6 in GC_clear_stack_inner (arg=0x0,
limit=0x7fff2dd5ce30 <Address 0x7fff2dd5ce30 out of bounds>) at
./misc.c:243<br>
243 ./misc.c: No such file or directory.<br>
in ./misc.c<br>
(gdb) info threads<br>
2 process 28526 0x00007fff316fcbe1 in nanosleep () from
/lib/libc.so.6<br>
* 1 process 28525 0x00000000005655b6 in GC_clear_stack_inner (arg=0x0,
limit=0x7fff2dd5ce30 <Address 0x7fff2dd5ce30 out of bounds>) at
./misc.c:243<br>
<br>
<br>
<blockquote cite="mid:20110524021131.724406500B9@mail-svr1.cs.utah.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
(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?<br>
<br>
<div class="moz-signature">-- <br>
<a class="moz-txt-link-freetext" href="http://www.neilvandyke.org/">http://www.neilvandyke.org/</a>
</div>
</body>
</html>