Red Hat Bugzilla – Bug 437660
emacs dumps core on SIGABRT
Last modified: 2008-03-17 14:00:14 EDT
Description of problem:
I found today 20M of a core file from emacs dumped yesterday.
After trying to recall what may cause that I believe that this may
be an effect of terminating a desktop session with emacs still
running. That seems to be supported by
error_message=0x7fff96090640 "Connection lost to X server `:0.0'"
from frame 69. OTOH I tried today to reproduce the problem and
after a number of tries so far I failed. That could be some sort
of a race on a termination.
A backtrace produced by gdb after emacs-debuginfo was installed
is attached. Please let me know if a core file is of any interest.
Version-Release number of selected component (if applicable):
I failed to repeat after five or six tries this core the way
as describe above. OTOH sending SIGABRT to a running emacs
process dumps core every time (with a suitable 'ulimit') although
backtrace is then only fifteen frames deep. Still emacs frames
look very similar to those in an attached backtrace.
That was on x86_64 but I would be surprised to find that this
is a requirement.
Created attachment 298165 [details]
gdb backtrace from a core produced by emacs
(In reply to comment #0)
> OTOH sending SIGABRT to a running emacs
> process dumps core every time (with a suitable 'ulimit')
? That is exactly how it is supposed to work!
$ ulimit -c unlimited
$ sleep 20 &
$ kill -ABRT 9314
+ Aborted (core dumped) sleep 20
$ file core.9314
core.9314: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style,
This is not a bug in "sleep". This is what SIGABRT is for.