Bug 86245 - emacs segfaults at random
Summary: emacs segfaults at random
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-18 01:38 UTC by Andrei Gaponenko
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-05-20 07:29:55 UTC

Attachments (Terms of Use)
My $HOME/.emacs file (10.21 KB, text/plain)
2003-03-18 01:45 UTC, Andrei Gaponenko
no flags Details

Description Andrei Gaponenko 2003-03-18 01:38:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:

Emacs core dumps every few days. The crashes are "random", i.e. I can
not correlate them to what I was doing. Today it crashed on 
Alt-x man <enter> topic <enter>, the other time on resizing a window, the other
time on opening a file, etc.

I usually use the same emacs session for a day, and often there are dozens of
buffers and a few frames simultaneously. But I observed crashes with a single
frame (like today) and only a few buffers.

It never happened with pre-21 emacs, all the trouble began after an upgrade to

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use a single emacs session with multiple buffers for a while. It does not
always crash, though.

Additional info: I'll attach a core dump and my .emacs file.

Comment 1 Andrei Gaponenko 2003-03-18 01:45:47 UTC
Created attachment 90635 [details]
My $HOME/.emacs file

Comment 2 Andrei Gaponenko 2003-03-18 01:49:48 UTC
The core dump can be found at http://e614db.triumf.ca/~andr/emacs-bug/
(bugzilla said it was too big for an attachment...)

Comment 3 Andrei Gaponenko 2003-03-19 00:08:26 UTC
There is one more core dump from today's crash (core.28111) on the web.

This time it crashed when I clicked "Buffers" on the menu bar.

(gdb) where
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x080da3bf in fatal_error_signal ()
#2  <signal handler called>
#3  0x40098e7d in XtWidgetToApplicationContext () from /usr/X11R6/lib/libXt.so.6
#4  0x4008e4ff in XtCallCallbacks () from /usr/X11R6/lib/libXt.so.6
#5  0x40030c13 in RepeatNotify () from /usr/X11R6/lib/libXaw3d.so.7
#6  0x400a882f in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#7  0x080b7b07 in x_process_timeouts ()
#8  0x0816edcc in alarm_signal_handler ()
#9  <signal handler called>
#10 0x420d3b2e in select () from /lib/i686/libc.so.6
#11 0x0001e7f7 in ?? ()
#12 0x0805707f in sit_for ()
#13 0x080df501 in read_char ()
#14 0x080e5914 in read_key_sequence ()
#15 0x080dd144 in command_loop_1 ()
#16 0x081371ea in internal_condition_case ()
#17 0x080dce2d in command_loop_2 ()
#18 0x08136d59 in internal_catch ()
#19 0x080dcdd7 in command_loop ()
#20 0x080dc89e in recursive_edit_1 ()
#21 0x080dc9d2 in Frecursive_edit ()
#22 0x080db27b in main ()
#23 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Comment 4 Jens Petersen 2003-03-21 11:03:28 UTC
What does the gdb backtrace of the first coredump look like?

It would be good if you could try the latest emacs package
in rawhide, to see if the problem still persists for you.
Since the lib in rawhide are probably newer than in 8.0,
you'll probably have to rebuild the package yourself on 8.0,
unless you want to install rawhide in a testbox and try that.

Comment 5 Jens Petersen 2003-05-20 07:29:55 UTC
Closing for now.  Please reopen if it is still happening with
Emacs 21.3 in rawhide.

Note You need to log in before you can comment on or make changes to this bug.