Bug 1127563 - [abrt] emacs: terminate_due_to_signal(): emacs-24.3 killed by SIGABRT
Summary: [abrt] emacs: terminate_due_to_signal(): emacs-24.3 killed by SIGABRT
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 21
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Petr Hracek
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:9df01f0d405e27bef1fed0c2797...
Depends On:
Blocks: 1124399
TreeView+ depends on / blocked
Reported: 2014-08-07 07:20 UTC by Matteo Settenvini
Modified: 2015-12-02 16:11 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-02 03:22:04 UTC

Attachments (Terms of Use)
File: backtrace (42.46 KB, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: cgroup (225 bytes, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: core_backtrace (14.59 KB, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: dso_list (13.44 KB, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: environ (180 bytes, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: limits (1.29 KB, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: maps (65.76 KB, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: open_fds (184 bytes, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: proc_pid_status (949 bytes, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
File: var_log_messages (204 bytes, text/plain)
2014-08-07 07:20 UTC, Matteo Settenvini
no flags Details
coredump from binary without optimizations (4.60 MB, application/octet-stream)
2014-08-07 10:02 UTC, Matteo Settenvini
no flags Details
full backtrace for the coredump without optimizations (35.60 KB, text/plain)
2014-08-07 13:05 UTC, Matteo Settenvini
no flags Details

System ID Priority Status Summary Last Updated
GNOME Bugzilla 85715 None None None Never

Description Matteo Settenvini 2014-08-07 07:20:33 UTC
Description of problem:
Running emacs in daemon mode at session startup through systemd --user.
Ccrash when also the containing X session crashes (e.g. gnome-shell crashes). Maybe in this case the error should be handled gracefully, and the daemon shut down?

I would probably mark this as a low priority item, though.

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/emacs --daemon
crash_function: terminate_due_to_signal
executable:     /usr/bin/emacs-24.3
kernel:         3.16.0-1.fc21.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #1 terminate_due_to_signal at /usr/src/debug/emacs-24.3/src/emacs.c:344
 #2 emacs_abort at /usr/src/debug/emacs-24.3/src/sysdep.c:2152
 #3 x_connection_closed at /usr/src/debug/emacs-24.3/src/xterm.c:7814
 #4 x_io_error_quitter at /usr/src/debug/emacs-24.3/src/xterm.c:7921
 #5 _XIOError at XlibInt.c:1498
 #7 XGetSelectionOwner at GetSOwner.c:41
 #8 get_prop_window at /usr/src/debug/emacs-24.3/src/xsettings.c:328
 #9 xft_settings_event at /usr/src/debug/emacs-24.3/src/xsettings.c:793
 #10 handle_one_xevent at /usr/src/debug/emacs-24.3/src/xterm.c:7048
 #11 event_handler_gdk at /usr/src/debug/emacs-24.3/src/xterm.c:5853

Potential duplicate: bug 995186

Comment 1 Matteo Settenvini 2014-08-07 07:20:36 UTC
Created attachment 924736 [details]
File: backtrace

Comment 2 Matteo Settenvini 2014-08-07 07:20:38 UTC
Created attachment 924737 [details]
File: cgroup

Comment 3 Matteo Settenvini 2014-08-07 07:20:40 UTC
Created attachment 924738 [details]
File: core_backtrace

Comment 4 Matteo Settenvini 2014-08-07 07:20:41 UTC
Created attachment 924739 [details]
File: dso_list

Comment 5 Matteo Settenvini 2014-08-07 07:20:43 UTC
Created attachment 924740 [details]
File: environ

Comment 6 Matteo Settenvini 2014-08-07 07:20:44 UTC
Created attachment 924741 [details]
File: limits

Comment 7 Matteo Settenvini 2014-08-07 07:20:46 UTC
Created attachment 924742 [details]
File: maps

Comment 8 Matteo Settenvini 2014-08-07 07:20:47 UTC
Created attachment 924743 [details]
File: open_fds

Comment 9 Matteo Settenvini 2014-08-07 07:20:49 UTC
Created attachment 924744 [details]
File: proc_pid_status

Comment 10 Matteo Settenvini 2014-08-07 07:20:50 UTC
Created attachment 924745 [details]
File: var_log_messages

Comment 11 Jan Chaloupka 2014-08-07 07:48:50 UTC
Hi, Matteo,

thank you for report. Can you reproduce this issue anytime? The backtrace still contains optimized out values which does not allow me to debug the crash.

Here is a build with optimization turned off.

Steps to create core with full backtrace information for emacs:

$ cd /tmp

download the latest emacs build from https://jchaloup.fedorapeople.org for your distribution and architecture (wget can be used). Should be always actual release in fedora + 1.
$ wget https://jchaloup.fedorapeople.org/emacs-24.3-23.fc20.x86_64.rpm

install downloaded rpm, release can vary
# rpm -Uvh emacs-24.3-23.fc20.x86_64.rpm

Then reproduce the issue and upload generated core.

After reproducing, just run
# yum distro-sync emacs

Maybe this time we will catch the issue :)


Comment 12 Jan Chaloupka 2014-08-07 08:32:14 UTC
Update for f21, the following build is correct:

wget https://jchaloup.fedorapeople.org/emacs-24.3-24.fc21.x86_64.rpm

Comment 13 Matteo Settenvini 2014-08-07 10:02:36 UTC
Created attachment 924847 [details]
coredump from binary without optimizations

Here we go. I installed the package with --nodeps, as I had a different version of emacs-common installed (no problem there).

Then I made sure emacs was running in daemon mode -- I have the following unit file in /etc/systemd/user/emacs@.service (then added with systemctl --user enable emacs@username"):


Description=Emacs: the extensible, self-documenting text editor

ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(progn (setq kill-emacs-hook 'nil) (kill-emacs))"



I then fired up emacsclient, and opened a file for editing.
Finally, I killed gdm: "sudo killall -11 gdm".

This was enough to reproduce the crash on my side.
Let me know if I can help further.

Comment 14 Jan Chaloupka 2014-08-07 11:03:21 UTC
The attached backtrace is diffrent from the first one. This one belongs to killall -ll gdm unfortunatelly.

The first crash, did it ocurred on its own? Did you kill emacs deamon before the crash?

Can you describe me all your actions, what were you doing before the accident? This is kind of a bug I have never been able to reproduce with a crash.

Comment 15 Matteo Settenvini 2014-08-07 11:26:09 UTC
You sure Jan that the coredump comes from gdm?
If I try to run:

  gdb /usr/sbin/gdm coredump

it says:

   Core was generated by `/usr/bin/emacs --daemon'.

And even though I don't have all the debuginfo installed, I can still produce a backtrace with it when specifying /usr/bin/emacs to gdb as the binary:

(gdb) bt
#0  0x0000003adf410699 in raise (sig=6) at ../sysdeps/unix/sysv/linux/pt-raise.c:36
#1  0x0000000000545f26 in terminate_due_to_signal ()
#2  0x000000000056bf1a in emacs_open ()
#3  0x00000000005114d4 in x_connection_closed ()
#4  0x00000000005116df in x_io_error_quitter ()
#5  0x0000003ae3c4557e in _XIOError (dpy=dpy@entry=0x3562300) at XlibInt.c:1498
#6  0x0000003ae3c42ebd in _XEventsQueued (dpy=dpy@entry=0x3562300, mode=mode@entry=2) at xcb_io.c:366
#7  0x0000003ae3c347d7 in XPending (dpy=0x3562300) at Pending.c:55
#8  0x0000003718651fde in gdk_check_xpending (display=display@entry=0x3573090 [GdkX11Display]) at gdkeventsource.c:266
#9  0x00000037186521ca in gdk_event_source_prepare (source=<optimized out>, timeout=timeout@entry=0x7fff66a29194) at gdkeventsource.c:284
#10 0x0000003ae144941d in g_main_context_prepare (context=context@entry=0x35898c0, priority=priority@entry=0x7fff66a29220) at gmain.c:3352
#11 0x0000003ae1449d7b in g_main_context_iterate (context=context@entry=0x35898c0, block=block@entry=0, dispatch=dispatch@entry=0, self=<optimized out>)
    at gmain.c:3714
#12 0x0000003ae1449f17 in g_main_context_pending (context=0x35898c0, context@entry=0x0) at gmain.c:3760
#13 0x0000003718c0459d in gtk_events_pending () at gtkmain.c:1284
#14 0x000000000050fd37 in XTread_socket ()
#15 0x00000000005551d9 in gobble_input ()
#16 0x0000000000555b6b in handle_async_input ()
#17 0x0000000000555b8a in process_pending_signals ()
#18 0x00000000005c67d9 in Fmake_list ()
#19 0x00000000005efce2 in concat ()
#20 0x00000000005ef593 in Fcopy_sequence ()
#21 0x0000000000550db4 in timer_check ()
#22 0x000000000054ec69 in readable_events ()
#23 0x0000000000554ffe in get_input_pending ()
#24 0x000000000055c79d in detect_input_pending_run_timers ()
#25 0x00000000006426b6 in wait_reading_process_output ()
#26 0x000000000054f886 in kbd_buffer_get_event ()
#27 0x000000000054d512 in read_char ()
#28 0x000000000055a168 in read_key_sequence ()
#29 0x000000000054a8c4 in command_loop_1 ()
#30 0x00000000005e804a in internal_condition_case ()
#31 0x000000000054a1de in command_loop_2 ()
#32 0x00000000005e79b4 in internal_catch ()
#33 0x000000000054a18c in command_loop ()
#34 0x00000000005498e6 in recursive_edit_1 ()
#35 0x0000000000549a89 in Frecursive_edit ()
#36 0x00000000005478a8 in main ()

Comment 16 Matteo Settenvini 2014-08-07 11:38:23 UTC
I've found the root cause, it's a known bug:

ago 07 13:16:08 violet.homegarden.local emacs[32111]: Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
ago 07 13:16:08 violet.homegarden.local emacs[32111]: Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
ago 07 13:16:08 violet.homegarden.local emacs[32111]: http://bugzilla.gnome.org/show_bug.cgi?id=85715
ago 07 13:16:08 violet.homegarden.local emacs[32111]: Warning: due to a long standing Gtk+ bug

This comes from xterm.c, line 7641 (http://goo.gl/8fpVeE).

Comment 17 Jan Chaloupka 2014-08-07 11:44:15 UTC
Yes, this is known bug. Still it is good to fix this bug. Could you send me the full backtrace? I am unable to display your backtrace. Thank you.

Comment 18 Matteo Settenvini 2014-08-07 12:34:39 UTC
Sure, can you provide me the emacs-debuginfo RPM corresponding to https://jchaloup.fedorapeople.org/emacs-24.3-24.fc21.x86_64.rpm ?

Comment 20 Matteo Settenvini 2014-08-07 13:05:25 UTC
Created attachment 924902 [details]
full backtrace for the coredump without optimizations

If we really want to fix this at the root, I think we want a build that does not unconditionally abort before showing the original symptoms -- that is, xterm.c with these lines removed:

#ifdef USE_GTK
      /* A long-standing GTK bug prevents proper disconnect handling
(https://bugzilla.gnome.org/show_bug.cgi?id=85715). Once,
the resulting Glib error message loop filled a user's disk.
To avoid this, kill Emacs unconditionally on disconnect. */
      shut_down_emacs (0, Qnil);
      fprintf (stderr, "%s\n\
When compiled with GTK, Emacs cannot recover from X disconnects.\n\
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715\n\
For details, see etc/PROBLEMS.\n",
      emacs_abort ();
#endif /* USE_GTK */

Else, it's always bailing out when it loses the connection to the X server due to a X server crash.

Comment 21 Fedora End Of Life 2015-11-04 10:07:55 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 22 Fedora End Of Life 2015-12-02 03:22:10 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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