Re: Crash of Emacs 22.1

[Stefan Monnier]

> Look at this, it seems to be the interessting part of the dump:

> #18 <signal handler called>
> #19 0x0812d0a9 in mem_delete (z=Variable "z" is not available.
> ) at alloc.c:3940
> #20 0x0812d30e in lisp_free (block=0x9621708) at alloc.c:893
> #21 0x08131386 in Fgarbage_collect () at alloc.c:6259
> #22 0x0816c992 in Fbyte_code (bytestr=136141291, vector=136141308, 
> maxdepth=48)
>     at bytecode.c:724

All this seems to indicate is that there's some memory corruption and
that the corruption caused a crash later on inside the GC (which is
usually where it happens since the GC looks at most of the memory).

Not much to go on.  The part of the stack trace just before entering the
GC might be a bit more enlightening, although I wouldn't hold my breath.

> Obviously the crash happened during a garbage collection. But at line
> 3940 of file alloc.c there is not routine "mem_delete".
> There is "mem_delete_fixup"...

> So it's no surprise when gdb says: z=Variable "z" is not available.

> Seeking for advice: How can I help to fix things here?

Fetch the Emacs-22.1 source code, so you can debug better, go to the
emacs/src directory (where there's a .gdbinit file which will provide
some extra commands) and then use `xbacktrace' which will give you
a Lisp-level backtrace (basically a more succint interpretation of
a subset of the C backtrace before the call to the GC).

Also, keep this core dump around, and try to reproduce the problem,
accumulating core dumps and stack backtraces over time, so we may be
able to find some pattern.  You may also want to run your Emacs
from within GDB so you'll always get a usable "core".
Also look at the emacs/etc/DEBUG file in the distribution.  Finally,
recompile without optimizations so GDB is a bit less confused by
variables that disappeared and things like that.


        Stefan