Bug 437660

Summary: emacs dumps core on SIGABRT
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: emacsAssignee: Chip Coldwell <coldwell>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-17 18:00:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
gdb backtrace from a core produced by emacs none

Description Michal Jaegermann 2008-03-15 20:53:04 UTC 
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 20:53:04 UTC 
Created attachment 298165 [details]
gdb backtrace from a core produced by emacs
Comment 2 Chip Coldwell 2008-03-17 14:26:21 UTC 
(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 17:59:39 UTC 
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