unpredictable emacs 21 crashes

unpredictable emacs 21 crashes

[Rob Reid]

Hi,

Since upgrading to emacs 21 a few months ago it hasn't stayed up for more than
a day or two on average.  I've been watching for a pattern without seeing any,
and I'm not sure but I think sometimes it even crashes in the middle of the
night when I'm not there.

TIA for any help.

168 ~% file core
core: ELF 32-bit LSB core file of 'emacs' (signal 11), Intel 80386, version 1
169 ~% gdb /usr/bin/emacs core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `emacs -geometry 81x42'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXaw3d.so.7...done.
Loaded symbols for /usr/X11R6/lib/libXaw3d.so.7
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXmu.so.6
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXt.so.6
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Loaded symbols for /usr/X11R6/lib/libSM.so.6
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Loaded symbols for /usr/X11R6/lib/libICE.so.6
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
Reading symbols from /usr/lib/libtiff.so.3...done.
Loaded symbols for /usr/lib/libtiff.so.3
Reading symbols from /usr/lib/libjpeg.so.62...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libpng.so.2...done.
Loaded symbols for /usr/lib/libpng.so.2
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libungif.so.4...done.
Loaded symbols for /usr/lib/libungif.so.4
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Loaded symbols for /usr/X11R6/lib/libXpm.so.4
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x403248d1 in __kill () from /lib/libc.so.6
(gdb) up
#1  0x80d6044 in fatal_error_signal ()
(gdb) up
#2  <signal handler called>
(gdb) up
#3  0x811d476 in mark_object ()
(gdb) up
#4  0x811d8ea in mark_object ()
(gdb) up
#5  0x811d932 in mark_object ()
(gdb) up
#6  0x811d8ea in mark_object ()
(gdb) 

(It kept returning to 0x811d8ea in mark_object () until I lost patience.)

173 ~% rpm -qf /usr/bin/emacs
emacs-21.1-0.2.9

(On Red Hat 7ish GNU/Linux.)

Re: unpredictable emacs 21 crashes

[Richard Stallman]

    (gdb) up
    #1  0x80d6044 in fatal_error_signal ()
    (gdb) up
    #2  <signal handler called>
    (gdb) up
    #3  0x811d476 in mark_object ()
    (gdb) up

This is a failure in GC.  It is natural that there would be many stack
frames recursively calling mark_object.  To find where GC was called,
try moving up the stack many frames at once.  Use `up 100' for
instance.  Try various numbers; do a binary search.

Most likely, whatever called GC won't be relevant.
The crash is probably due to invalid data.  To analyze it
you need to study the data being worked on in the innermost frames.
By working back one frame at a time, you can see what data structure
the invalid objects are found in.  The vector last_marked (see
alloc.c) can help you trace this back.

Once you see if there is a pattern to that, we might have an idea
where to look for the real problem.

This analysis process is nontrivial, but there's no shortcut
except to be very very lucky.

Re: unpredictable emacs 21 crashes

[Eli Zaretskii]

On Sat, 15 Jun 2002, Richard Stallman wrote:

> Most likely, whatever called GC won't be relevant.
> The crash is probably due to invalid data.  To analyze it
> you need to study the data being worked on in the innermost frames.
> By working back one frame at a time, you can see what data structure
> the invalid objects are found in.  The vector last_marked (see
> alloc.c) can help you trace this back.

There's some information about debugging these problems in etc/DEBUG.