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: emacs-24.3-22.fc21 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
Created attachment 924736 [details] File: backtrace
Created attachment 924737 [details] File: cgroup
Created attachment 924738 [details] File: core_backtrace
Created attachment 924739 [details] File: dso_list
Created attachment 924740 [details] File: environ
Created attachment 924741 [details] File: limits
Created attachment 924742 [details] File: maps
Created attachment 924743 [details] File: open_fds
Created attachment 924744 [details] File: proc_pid_status
Created attachment 924745 [details] File: var_log_messages
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 :) Thanks Jan
Update for f21, the following build is correct: wget https://jchaloup.fedorapeople.org/emacs-24.3-24.fc21.x86_64.rpm
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"): ------------------------------------------------ [Unit] Description=Emacs: the extensible, self-documenting text editor [Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval "(progn (setq kill-emacs-hook 'nil) (kill-emacs))" Restart=always RestartSec=1 [Install] WantedBy=default.target ------------------------------------------------ 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.
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.
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 ()
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).
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.
Sure, can you provide me the emacs-debuginfo RPM corresponding to https://jchaloup.fedorapeople.org/emacs-24.3-24.fc21.x86_64.rpm ?
http://koji.fedoraproject.org/koji/taskinfo?taskID=7253703
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", error_msg); 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.
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.