bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs core dump


From: Eli Zaretskii
Subject: Re: Emacs core dump
Date: Thu, 14 Jun 2001 10:56:34 +0300

On Wed, 13 Jun 2001, Cyprian Laskowski wrote:

> Ok, I've been meaning to learn gdb forever, so now's as good a time as
> any.  I got some backtraces.  But I'm not really sure what to do with
> them, other than printing them back out to you here. :)
> 
> (Please tell me if it's unacceptable to be posting so much output to
> the newsgroup.)

It is acceptable if necessary.  But you should always begin by showing
only the few _innermost_ levels -- those which begin at level #0 --
because these are usually the only ones relevant to the crash.

> They are not identical, but they do end up basically the same way (I
> hope this isn't common to all Emacs unpleasant exits!):
> 
> (emacs 20.3.1:)
> 
> ----------
> #904 0x80e748a in internal_catch (tag=404699588, func=0x8095984 
> <command_loop_2>, arg=404699108) at eval.c:925
> #905 0x8095953 in command_loop () at keyboard.c:1072
> #906 0x80955d4 in recursive_edit_1 () at keyboard.c:821
> #907 0x80956b7 in Frecursive_edit () at keyboard.c:869
> #908 0x80948ae in main (argc=1, argv=0xbffff9d4, envp=0xbffff9dc) at 
> emacs.c:1361
> ------------

The end will be always almost identical, because that's the bottom of
the call stack: it just tells you that whatever code was running at
the moment of the crash, it was invoked from the `main' function.
These last levels are almost never interesting.

> Here are the two shortest backtraces in full off of my Sun 20.3.1 Emacs:
> 
> ------------
> (gdb) backtrace
> #0  0xef40878c in _pthread_testcancel ()
> #1  0x9e0fc in fatal_error_signal (sig=11) at emacs.c:246
> #2  0xef3b89e4 in _setpgid ()
> #3  0xc4ffc in adjust_intervals_for_insertion (tree=0x55401c, position=424, 
> length=1)
>     at intervals.c:416
> #4  0xc77a0 in offset_intervals (buffer=0x599a70, start=424, length=1) at 
> intervals.c:1343
> #5  0xbe9ac in insert_1_both (string=0xefffeb60 "\n", nchars=1, nbytes=1, 
> inherit=1, prepare=0, 
>     before_markers=0) at insdel.c:1123
> #6  0xbe0dc in insert_1 (string=0xefffeb60 "\n", nbytes=1, inherit=1, 
> prepare=1, before_markers=0)
>     at insdel.c:892

This seems related to the intervals data structure.

> (gdb) backtrace
> #0  0xef40880c in _kill ()
> #1  0x9e0fc in fatal_error_signal (sig=6) at emacs.c:246
> #2  <signal handler called>
> #3  0xef40880c in _kill ()
> #4  0x9e118 in abort () at emacs.c:274
> #5  0xc41f4 in find_interval (tree=0x67d3a0, position=1104) at intervals.c:596
> #6  0xc68dc in set_point_both (buffer=0x6081b0, charpos=1104, bytepos=1104) 
> at intervals.c:1815
> #7  0xfc6c0 in Fgoto_char (position=540124008) at editfns.c:223

Same here.

> 971       if (NILP (symbol) || EQ (symbol, Qt)
> DISPLAY = kromm:10.0
> TERM = xterm
> Breakpoint 1 at 0x8093887: file emacs.c, line 282.
> Breakpoint 2 at 0x8085a2e: file xterm.c, line 5335.
> (gdb) backtrace
> ....
> #866 0x80d98de in mark_object (argptr=0x8235e44) at alloc.c:2287
> #867 0x80d9751 in mark_object (argptr=0x828ec94) at alloc.c:2181
> #868 0x80d98de in mark_object (argptr=0x82adf30) at alloc.c:2287

You omitted the innermost stack levels, so it is impossible to say
what's going on here.

> 0x813a104 "byte-code"
> 0x84ff740 "eshell-exec-lisp"
> 0x813a104 "byte-code"
> 0x84e069c "eshell-lisp-command"
> 0x84ff60c "eshell-plain-command"
> 0x84e0678 "eshell-named-command"

This seems to indicate that you are using Eshell.  Since Eshell is not
an integral part of Emacs 20.x, perhaps you have an old version that
has some bug.  I suggest to try to upgrade to a newer version of
Eshell and see if the crashes go away.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]