Bug 437660 - emacs dumps core on SIGABRT
emacs dumps core on SIGABRT
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Chip Coldwell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-15 16:53 EDT by Michal Jaegermann
Modified: 2008-03-17 14:00 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-17 14:00:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gdb backtrace from a core produced by emacs (10.74 KB, text/plain)
2008-03-15 16:53 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2008-03-15 16:53:04 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):
emacs-22.1.50-4.fc9

How reproducible:
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.
Comment 1 Michal Jaegermann 2008-03-15 16:53:04 EDT
Created attachment 298165 [details]
gdb backtrace from a core produced by emacs
Comment 2 Chip Coldwell 2008-03-17 10:26:21 EDT
(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!
Comment 3 Chip Coldwell 2008-03-17 13:59:39 EDT
For example:

$ ulimit -c unlimited
$ sleep 20 &
[1] 9314
$ kill -ABRT 9314
$ 
[1]+  Aborted                 (core dumped) sleep 20
$ file core.9314 
core.9314: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style,
from 'sleep'

This is not a bug in "sleep".  This is what SIGABRT is for.

Chip

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