I'm still not sure what the problem is, since I've been dealing<br>with so many different versions of ccl over the last few days.<br><br>I distinctly remember seeing MAP_GROWSDOWN in the<br>call to mmap() from MapMemoryForStack(), but I just looked <br>
in the 1.5 release, and it isn't there. So, I must have been<br>running something else.<br><br>I'll keep an eye out from now on by running ccl under gdb<br>with the right .gdbinit, and keep you guys posted if<br>anything shows up.<br>
<br>Thanks for all the help, BTW... I appreciate the responsiveness<br>with which you have responded on this matter.<br><br><div class="gmail_quote">On Thu, Nov 18, 2010 at 3:02 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">When running under GDB, it's necessary to tell GDB to ignore the<br>
signals that CCL's own exception-handling mechanisms handle.  See<br>
<<a href="http://trac.clozure.com/ccl/wiki/CclUnderGdb" target="_blank">http://trac.clozure.com/ccl/wiki/CclUnderGdb</a>><br>
(You basically need to tell GDB to "source" a platform-specific<br>
.gdbinit file that tells it which signals should be quietly passed<br>
to the application.)<br>
What you're seeing here is very likely expected behavior: the initial lisp thread has started running, tries to allocate some<br>
lisp object, finds that it doesn't have any memory to cons in,<br>
and executes a software interrupt that (on Linux) maps to SIGSEGV.<br>
GDB's proudly announcing that it's noticed this, but hasn't yet<br>
passed the signal on to CCL's handler, which should try to give<br>
the thread a chunk of memory to cons in, skip over the interrupt<br>
instruction, and allow the thread to resume execution.<br>
A relatively recent change in the Linux kernel (described in<br>
<<a href="http://trac.clozure.com/ccl/ticket/731" target="_blank">http://trac.clozure.com/ccl/ticket/731</a>>)<br>
causes one of those calls to mmap() (the first one that tries to map memory<br>
for a stack) to fail, since the address returned by mmap() in that case isn't<br>
actually mapped.  This usually causes a very hard crash on startup; I -think-<br>
that that happens pretty deterministically, but I'm not sure of that (and if<br>
not, it'd be a likely explanation for sporadic crashes on startup.)<br>
That problem seems to be triggered by use of the MAP_GROWSDOWN option in<br>
the call to mmap that allocates stacks.  MAP_GROWSDOWN doesn't do what we<br>
thought it does, and we've removed it from the sources in svn in 1.5 and<br>
I don't know if that's the cause of the problem that you're (sometimes)<br>
seeing; if you haven't already done so, it'd probably be a good idea to<br>
disable that option (if only to remove a variable from the equation.)<br>
The output below indicates that you got past that, started to run<br>
some lisp code, that lisp code consed, and GDB (mistakenly) thought<br>
that that was notable.  It isn't.  We don't know whether you would<br>
have run into some other problem after consing or whether what you've<br>
been seing is just the problem described in ticket 731; if you have<br>
been seeing that problem, the workaround seems to work reliably.<div><div></div><div class="h5"><br>
On Thu, 18 Nov 2010, Bit Twiddler wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm getting sporadic crashes starting ccl on various linuxes<br>
(CentOS 5.5, Scientific Linux 5.5, and Open Suse 11.3)<br>
Current directory is ~/p/cl/ccl/1.5/release/ccl/<br>
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)<br>
Copyright (C) 2009 Free Software Foundation, Inc.<br>
License GPLv3+: GNU GPL version 3 or later<br>
<<a href="http://gnu.org/licenses/gpl.html" target="_blank">http://gnu.org/licenses/gpl.html</a>><br>
This is free software: you are free to change and redistribute it.<br>
There is NO WARRANTY, to the extent permitted by law.? Type "show copying"<br>
and "show warranty" for details.<br>
This GDB was configured as "x86_64-redhat-linux-gnu".<br>
For bug reporting instructions, please see:<br>
<<a href="http://www.gnu.org/software/gdb/bugs/" target="_blank">http://www.gnu.org/software/gdb/bugs/</a>>...<br>
Reading symbols from<br>
(gdb) run<br>
Starting program: /mnt/data1/home1/xxx/p/cl/ccl/1.5/release/ccl/lx86cl64<br>
[Thread debugging using libthread_db enabled]<br>
Reserving heap at 0x300000000000, size 0x8000000000<br>
Committing memory at 0x302000000000, size 0x540000<br>
Committing memory at 0x307c00000000, size 0xb000<br>
Committing memory at 0x307e3f800000, size 0xb000<br>
Committing memory at 0x302000540000, size 0x2000000<br>
Committing memory at 0x307c0000b000, size 0x40000<br>
Unprotecting memory at 0x307c0000b000, size 0x40000<br>
Committing memory at 0x307e3f80b000, size 0x40000<br>
Unprotecting memory at 0x307e3f80b000, size 0x40000<br>
Mapping stack of size 0x24d000<br>
Protecting memory at 0x2aaaaaacb000, size 0x1000<br>
Protecting memory at 0x2aaaaaacc000, size 0x19000<br>
Mapping stack of size 0x51000<br>
Protecting memory at 0x2aaaaad18000, size 0x10000<br>
Program received signal SIGSEGV, Segmentation fault.<br>
0x0000300000ab133f in ?? ()<br>
(gdb) bt<br>
#0? 0x0000300000ab133f in ?? ()<br>
#1? 0x000030200052f8af in ?? ()<br>
#2? 0x00002aaaaad16ff0 in ?? ()<br>
#3? 0x00000000004122c4 in toplevel_loop () at ../x86-subprims64.s:60<br>
Backtrace stopped: frame did not save the PC<br>
I don't understand why gdb can't display the backtrace, I have<br>
the optimizer turned off, and -g turned on.<br>
Previously, I was able to get a crash after a mmap call to allocate<br>
a stack segment, but now the program runs after that, and I wind<br>
up with the above situation.<br>
Does anybody know of any debugging code that I can enable?<br>
I turned on DEBUG_MEMORY by setting it to 1 in memory.c<br>