abrt 1.0.8 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: emacs /home/qralston/.mulberry/Temporary_Files/External_Edit/MulberryExternalEdit.txt component: emacs executable: /usr/bin/emacs-23.1 kernel: 2.6.32.10-92.fc12.x86_64 package: emacs-1:23.1-20.fc12 rating: 4 reason: Process /usr/bin/emacs-23.1 was killed by signal 7 (SIGBUS) release: Fedora release 12 (Constantine) comment ----- I use sawfish as my window manager. In window context, I have "Move window interactively" bound to Meta-Button1-Control-Click. Whenever Emacs process is starting, if I grab the Emacs window and attempt to move it, Emacs sometimes crashes. It does not happen every time, and I've never been successful at reproducing the problem at will; it only happens when I'm not trying to reproduce it. Mostly, Emacs tends to crash in this way when I launch it as an external editor from my mail client. However, the reason for that might be that when I launch Emacs by clicking its icon on the GNOME panel (which is on the bottom of my screen), Emacs finishes initializing before I can move the cursor back to the top of the screen and grab the window; in contrast, when I launch it from my mail client, the pointer is close enough to where the Emacs window appears that I can grab the window and move it while Emacs is still initializing. Emacs never crashes if I wait until it has fully initialized before I attempt to move the window. How to reproduce ----- 1. Launch Emacs. 2. Wait for the Emacs window to appear. 3. Before Emacs finishes initializing, grab and move the Emacs window.
Created attachment 404208 [details] File: backtrace
*** This bug has been marked as a duplicate of bug 549728 ***
This bug appears to have been filled using a buggy version of ABRT, because it contains a backtrace which is a duplicate of backtrace from bug #549728. Sorry for the inconvenience.
In response to comment 3: Karel, are you sure that this bug is a duplicate of bug 549728? This crash was caused due to SIGBUS; in bug 549728, the crash occurred due to SIGSEGV. Additionally, the stack backtrace in bug 549728 is incomplete (and thus useless), while the stack backtrace I attached is complete...
Hi James, I think it is the same bug. Getenv call crashes on Emacs startup due to memory corruption (caused by a race condition?). Unfortunately I do not see where the actual flaw is. #3 getenv (name=0x3a3dd3b4aa "NGUAGE") at getenv.c:84 ep_start = Cannot access memory at address 0x51f00000020037f Thank you for the bug report, both the backtrace and comment are useful.