Bug 1127563

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.