|Summary:||emacs segfaults at random|
|Product:||[Retired] Red Hat Linux||Reporter:||Andrei Gaponenko <andr>|
|Component:||emacs||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED WORKSFORME||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-05-20 07:29:55 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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 RH8.0. Version-Release number of selected component (if applicable): emacs-21.2-18 How reproducible: Sometimes 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. http://e614db.triumf.ca/~andr/emacs-bug/ 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 (gdb)
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.