Help debugging an Emacs crash

Help debugging an Emacs crash

[Daniel Barrett]

I am experiencing emacs segmentation faults under X. They occur at
random times, but always at the moment I press a key.  What is the
best way to debug this kind of problem?  I would be happy to enable
debugging in some way, and send you any useful information.

The crashes occur only within Kyle Jones's Emacs mail reader package "VM".
However, VM should not be able to crash emacs, so there must be an
underlying emacs or X bug.

The crashes never occur if I've run "emacs -nw" in an xterm.  Only
after running "emacs &" to open an Emacs X window.

Symptoms: Use VM for a while. At some point when I press a key, the X
window closes and emacs crashes with a segmentation fault error.  No
core dump.

System: Suse Linux 9.1 on Pentium 4 with 2 GB RAM.
Suse kernel 2.6.5-7.145-smp #1 SMP.
emacs-version: GNU Emacs 21.3.1 (i586-suse-linux, X toolkit, Xaw3d
scroll bars) of 2004-04-05 on gray

--
Dan Barrett
dbarrett@blazemonger.com

Re: Help debugging an Emacs crash

[Eli Zaretskii]

> Date: Mon, 4 Apr 2005 13:24:54 -0400
> From: Daniel Barrett <dbarrett@blazemonger.com>
> Cc: Daniel Barrett <dbarrett@blazemonger.com>
> 
> I am experiencing emacs segmentation faults under X. They occur at
> random times, but always at the moment I press a key.  What is the
> best way to debug this kind of problem?  I would be happy to enable
> debugging in some way, and send you any useful information.

Thanks.

For starters, please run GDB on the core file and post here a
traceback for these crashes.

Next, please read the file etc/DEBUG in the Emacs distribution which
gives some tips on debugging Emacs.

Re: Help debugging an Emacs crash

[Daniel Barrett]

On April 5, 2005, Eli Zaretskii wrote:
>> I am experiencing emacs segmentation faults under X....
>For starters, please run GDB on the core file and post here a
>traceback for these crashes.

I'd be happy to, but there's no core file generated.  Just a segfault.

>Next, please read the file etc/DEBUG in the Emacs distribution which
>gives some tips on debugging Emacs.

Thanks - I'll start running emacs under gdb and see what happens.

--
Dan Barrett
dbarrett@blazemonger.com

Re: Help debugging an Emacs crash

[Daniel Barrett]

On April 4, 2005, Daniel Barrett wrote:
>On April 5, 2005, Eli Zaretskii wrote:
>>> I am experiencing emacs segmentation faults under X....
>>For starters, please run GDB on the core file and post here a
>>traceback for these crashes.
>
>I'd be happy to, but there's no core file generated.  Just a segfault.
>
>>Next, please read the file etc/DEBUG in the Emacs distribution which
>>gives some tips on debugging Emacs.
>
>Thanks - I'll start running emacs under gdb and see what happens.

Unfortunately it looks like SUSE's emacs is compiled without debugging
symbols. Here's a stack trace of the crash...

Program received signal SIGSEGV, Segmentation fault.
0x403ba615 in bcopy () from /lib/tls/libc.so.6
(gdb) bt
#0  0x403ba615 in bcopy () from /lib/tls/libc.so.6
#1  0x080516f3 in ?? ()
#2  0x10fe5d1c in ?? ()
#3  0x10ffbdc4 in ?? ()
#4  0x000160a8 in ?? ()
#5  0x088215a8 in ?? ()
#6  0x088215fc in ?? ()
#7  0x000160a8 in ?? ()
#8  0x087b8258 in ?? ()
#9  0x11011e6c in ?? ()
#10 0x087ce300 in ?? ()
#11 0x10ffbdc4 in ?? ()
#12 0xbfffdf38 in ?? ()
#13 0x0812ab49 in re_search ()
Previous frame identical to this frame (corrupt stack?)

I imagine this isn't very helpful.  I'll grab the sources, build my
own Emacs, and see if the problem remains.

--
Dan Barrett
dbarrett@blazemonger.com

Re: Help debugging an Emacs crash

[Richard Stallman]

How about trying the development version of Emacs, in CVS on
savannah.gnu.org.

Re: Help debugging an Emacs crash

[Eli Zaretskii]

> Date: Mon, 4 Apr 2005 17:27:26 -0400
> Cc: dbarrett@blazemonger.com, bug-gnu-emacs@gnu.org
> From: Daniel Barrett <dbarrett@blazemonger.com>
> 
> On April 5, 2005, Eli Zaretskii wrote:
> >> I am experiencing emacs segmentation faults under X....
> >For starters, please run GDB on the core file and post here a
> >traceback for these crashes.
> 
> I'd be happy to, but there's no core file generated.  Just a segfault.

Perhaps your shell's init file limits the max size of a core file to
zero.

Re: Help debugging an Emacs crash

[Eli Zaretskii]

> Date: Mon, 4 Apr 2005 22:38:03 -0400
> Cc: bug-gnu-emacs@gnu.org, Daniel Barrett <dbarrett@blazemonger.com>
> From: Daniel Barrett <dbarrett@blazemonger.com>
> 
> I imagine this isn't very helpful.

Indeed.

> I'll grab the sources, build my own Emacs, and see if the problem
> remains.

If you are going to build Emacs, I'd suggest to follow Richard's
advice and grab the CVS version.

Re: Help debugging an Emacs crash

[Daniel Barrett]

On April 5, 2005, Eli Zaretskii wrote:
>> I am experiencing emacs segmentation faults under X. They occur at
>> random times, but always at the moment I press a key.  What is the
>> best way to debug this kind of problem?  I would be happy to enable
>> debugging in some way, and send you any useful information.
>>
>> The crashes occur only within Kyle Jones's Emacs mail reader package "VM".
>> However, VM should not be able to crash emacs, so there must be an
>> underlying emacs or X bug.
>
>For starters, please run GDB on the core file and post here a
>traceback for these crashes.

OK, after installing emacs 21.4.1 and running in gdb for a week, I finally
captured a segfault in the vm mailer. The stacktrace is below.

Also, I don't know if this is related, but emacs also "stopped" many times
during the week, i.e., gdb and its invoking shell displayed:

[1]+  Stopped                 gdb /usr/local/emacs-21.4/bin/emacs
$ fg
gdb /usr/local/emacs-21.4/bin/emacs
---Type <return> to continue, or q <return> to quit---

Pressing <return> resumed the Emacs session.

Here's the backtrace.  I'll leave gdb running and will gladly type any
debugging commands you request.

emacs-version:
(GNU Emacs 21.4.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2005-04-05 on myhost)

Program received signal SIGSEGV, Segmentation fault.
make_uninit_multibyte_string (nchars=9, nbytes=9) at alloc.c:1330
1330      string_free_list = NEXT_FREE_LISP_STRING (s);
(gdb) bt
#0  make_uninit_multibyte_string (nchars=9, nbytes=9) at alloc.c:1330
#1  0x081238d4 in make_specified_string (
    contents=0xbfffc2a0 "image/gif\234v+\030T^[%G�^[%@X^[%G��^[%@0Z\022\b\234v+\030\t", nchars=9, nbytes=9, multibyte=0) at alloc.c:1825
#2  0x0810fe79 in Fregexp_quote (string=946891788) at search.c:2876
#3  0x0813609d in Ffuncall (nargs=2, args=0xbfffc354) at eval.c:2670
#4  0x0816200b in Fbyte_code (bytestr=946891788, vector=1215331760, maxdepth=4)
    at bytecode.c:716
#5  0x08135b1b in funcall_lambda (fun=1215331912, nargs=2,
    arg_vector=0xbfffc464) at eval.c:2851
#6  0x08135ee5 in Ffuncall (nargs=3, args=0xbfffc460) at eval.c:2716
#7  0x0816200b in Fbyte_code (bytestr=948339124, vector=1215333080, maxdepth=3)
    at bytecode.c:716
#8  0x08135b1b in funcall_lambda (fun=1215333384, nargs=2,
    arg_vector=0xbfffc574) at eval.c:2851
#9  0x08135ee5 in Ffuncall (nargs=3, args=0xbfffc570) at eval.c:2716
#10 0x0816200b in Fbyte_code (bytestr=1484510828, vector=1215357152,
    maxdepth=8) at bytecode.c:716
#11 0x08135b1b in funcall_lambda (fun=1215357352, nargs=1,
    arg_vector=0xbfffc694) at eval.c:2851
#12 0x08135ee5 in Ffuncall (nargs=2, args=0xbfffc690) at eval.c:2716
#13 0x0816200b in Fbyte_code (bytestr=1216462656, vector=1215341480,
    maxdepth=3) at bytecode.c:716
#14 0x08135352 in Feval (form=1483771164) at eval.c:2023
#15 0x08137af8 in Fcondition_case (args=140891824) at eval.c:1211
#16 0x081617cc in Fbyte_code (bytestr=945272068, vector=1215341544, maxdepth=7)
    at bytecode.c:898
#17 0x08135b1b in funcall_lambda (fun=1215341896, nargs=1,
    arg_vector=0xbfffca14) at eval.c:2851
#18 0x08135ee5 in Ffuncall (nargs=2, args=0xbfffca10) at eval.c:2716
#19 0x0816200b in Fbyte_code (bytestr=1216462656, vector=1215337504,
    maxdepth=6) at bytecode.c:716
#20 0x08135b1b in funcall_lambda (fun=1215340096, nargs=0,
    arg_vector=0xbfffcad0) at eval.c:2851
#21 0x08135cbd in apply_lambda (fun=1215340096, args=405300268, eval_flag=1)
    at eval.c:2770
#22 0x081350c9 in Feval (form=1483728204) at eval.c:2071
#23 0x08137af8 in Fcondition_case (args=140891824) at eval.c:1211
#24 0x081617cc in Fbyte_code (bytestr=1482072116, vector=1215498744,
    maxdepth=6) at bytecode.c:898
#25 0x08135b1b in funcall_lambda (fun=1215499032, nargs=0,
    arg_vector=0xbfffce54) at eval.c:2851
#26 0x08135ee5 in Ffuncall (nargs=1, args=0xbfffce50) at eval.c:2716
#27 0x0816200b in Fbyte_code (bytestr=409617732, vector=1213693560, maxdepth=9)
    at bytecode.c:716
#28 0x08135b1b in funcall_lambda (fun=1215288520, nargs=1,
    arg_vector=0xbfffcfb4) at eval.c:2851
#29 0x08135ee5 in Ffuncall (nargs=2, args=0xbfffcfb0) at eval.c:2716
#30 0x081330e7 in Fcall_interactively (function=408680940,
    record_flag=405300268, keys=1210665384) at callint.c:797
#31 0x080dd0b3 in Fcommand_execute (cmd=408680940, record_flag=405300268,
    keys=405300268, special=405300268) at keyboard.c:9250
#32 0x080e767c in command_loop_1 () at keyboard.c:1661
#33 0x08134aea in internal_condition_case (bfun=0x80e72a0 <command_loop_1>,
    handlers=405396612, hfun=0x80e2f40 <cmd_error>) at eval.c:1267
#34 0x080e2b0c in command_loop_2 () at keyboard.c:1245
#35 0x08134bc2 in internal_catch (tag=200, func=0x80e2af0 <command_loop_2>,
    arg=405300268) at eval.c:1030
#36 0x080e2c41 in command_loop () at keyboard.c:1224
#37 0x080e2ce6 in recursive_edit_1 () at keyboard.c:950
#38 0x080e2dff in Frecursive_edit () at keyboard.c:1006
#39 0x080d9f40 in main (argc=3, argv=0xbfffd7d4, envp=0xbfffd7e4)
    at emacs.c:1547

(gdb) down 39
#0  make_uninit_multibyte_string (nchars=9, nbytes=9) at alloc.c:1330
1330      string_free_list = NEXT_FREE_LISP_STRING (s);

(gdb) list
1325          total_free_strings += STRINGS_IN_STRING_BLOCK;
1326        }
1327
1328      /* Pop a Lisp_String off the free-list.  */
1329      s = string_free_list;
1330      string_free_list = NEXT_FREE_LISP_STRING (s);
1331
1332      /* Probably not strictly necessary, but play it safe.  */
1333      bzero (s, sizeof *s);
1334

(gdb) p total_free_strings
$1 = 52

(gdb) p string_free_list
$2 = (struct Lisp_String *) 0xc8

(gdb) p *string_free_list
Cannot access memory at address 0xc8

--
Dan Barrett
dbarrett@blazemonger.com

Re: Help debugging an Emacs crash

[Richard Stallman]

Can you see if the problem still happens in the latest development Emacs 
from CVS on savannah.gnu.org?

Re: Help debugging an Emacs crash

[Daniel Barrett]

On April 13, 2005, Richard Stallman wrote:
>>I am experiencing emacs segmentation faults under X. They occur at
>>random times, but always at the moment I press a key.
>Can you see if the problem still happens in the latest development Emacs 
>from CVS on savannah.gnu.org?

I've now been running the latest dev Emacs for 2 weeks and the problem has
not occurred.

--
Dan Barrett
dbarrett@blazemonger.com

Re: Help debugging an Emacs crash

[Richard Stallman]

    I've now been running the latest dev Emacs for 2 weeks and the problem has
    not occurred.

That is good news.