[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-help
Subject:    Re: [Sbcl-help] analyzing crash
From:       Juho Snellman <jsnell () iki ! fi>
Date:       2007-12-18 13:39:24
Message-ID: 878x3s2kc3.fsf () vasara ! proghammer ! com
[Download RAW message or body]

"Alex Mizrahi" <alex.mizrahi@gmail.com> writes:
> helo
> 
> SBCL 1.0.12 crashes on Linux x86_64 (CentOS 5, 2.6.18-8.el5) with
> messages like this:
> 
> -----
> debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD
> "iolib worker 0" {1003C2A511}>:
>   Unhandled memory fault at #x0.
> -----
> Final object pointer 0x2aacb0e6dde0, start 0x2aaab0e62000, end 0x2aaab0e62570
> fatal error encountered in SBCL pid 19749(tid 46912611776816):
> GC invariant lost, file "gc-common.c", line 197
> -----
> 
> it happens on a multithreaded web server using UCW and iolib.
> 
> what would be suggestions on debugging this error?

The GC invariant lost message is basically telling that some memory
corruption has happened, and the GC was the first one to notice
it. It's hard to debug that after the fact. A backtrace will basically
be useless, since it won't tell you anything about which piece of
memory was corrupted, let alone what corrupted it.

The iolib message is also somewhat suggestive of either memory
corruption having happened, or memory corruption just happening. So
figuring out what is going on there might be a good first step. So
compile your application and libraries with a higher debug level, get
a backtrace (or even better, a slime debugger), and see what exactly
is referencing the null pointer. Then figure out why it's doing so :-)

Also, to ensure that everything is being compiled at maximum safety,
you could remove all fasls, (sb-ext:restrict-compiler-policy 'safety
3) and then recompile. This would help if the memory corruption is
caused by Lisp code, e.g. some (safety 0) code doing an out of bounds
array write, but not if it's something done by foreign code.

> also i suspect there are less chanced crashing when only one thread is
> used, is that correct?

Having just one thread would reduce the chance of some kinds of errors
(e.g. the GC moving an array that a foreign function has a pointer
to).

-- 
Juho Snellman


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Sbcl-help mailing list
Sbcl-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
[prev in list] [next in list] [prev in thread] [next in thread]