unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18375: 24.4.50; Emacs hangs X session manager logout in certain cases
@ 2014-08-31 11:56 Christoph Ruegge
  2014-09-01 11:40 ` Christoph Ruegge
  2014-09-02 18:25 ` Stefan Monnier
  0 siblings, 2 replies; 11+ messages in thread
From: Christoph Ruegge @ 2014-08-31 11:56 UTC (permalink / raw)
  To: 18375

I experience a bug that can be produced as follows:

(1) start emacs -Q --daemon
(2) open an X frame
(3) close the frame
(4) logout.

The result is that the session manager (KDE's, in my case) logout hangs
since Emacs does not respond to the logout signal. The bug does not
occur if I logout before closing the frame, or open other frames and
interact with Emacs in any way that does not lead to no frame being open
at any given time (I can even close the first frame). Moreover, if I
logout before opening any frame, the logout does not hang, but the Emacs
process does not terminate.

I investigated a bit and think the reason has something to do with the
way the SM communication is tied to the first opened terminal. The
connection is opened at the end of x_term_init() when the first terminal
is opened (and is an X terminal). Once the last X frame is closed, the
terminal is closed as well. I don't know precisely why this causes the
bug, since the SM connection is supposed to be shut down in
x_delete_display(), but I am pretty sure that the bug happens if and
only if the first terminal has been closed.

Far as I see, the bug occurs only on non-GTK toolkits, since for GTK the
terminal is kept open to circumvent some GTK some bug, apparently.

If I may add, the current behaviour is rather weird to begin with. The
SM integration's purpose is to cleanly shutdown Emacs on logout, so it
should be tied to the entire process and not to a particular
terminal. There are essentially two scenarios for the Emacs daemon: it
can be run outside a desktop session (in which case there should be no
SM connection at all) or inside (in which case the connection should
last for the lifetime of the process). A cleaner approach would
therefore maybe be to seperate the SM connection from opening and
closing the terminal and have it done at startup if the user wishes,
maybe depending on a command line parameter, the presence of the DISPLAY
variable, or after user init depending on some elisp variable. The
connection itself could maybe be done through a dummy X terminal that is
kept open all the time. I tried simpy adding a call to
`x-open-connection' to startup.el, and this indeed fixes the bug (for
one of the use cases).

I'd be willing to try to write a patch for this, but as I'm not much of
a programmer and do not really understand the way Emacs handles
displays, it would likely not be up to quality standards.

Best regards



In GNU Emacs 24.4.50.16 (x86_64-unknown-linux-gnu)
 of 2014-08-30 on io
Windowing system distributor `The X.Org Foundation', version 11.0.11600000
System Description:	Arch Linux

Configured using:
 `configure --prefix=/home/cs/.local --with-x-toolkit=no --without-gconf
 --without-gsettings

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE LIBOTF XFT ZLIB





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-09-04  5:40 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-31 11:56 bug#18375: 24.4.50; Emacs hangs X session manager logout in certain cases Christoph Ruegge
2014-09-01 11:40 ` Christoph Ruegge
2014-09-01 16:54   ` Christoph Ruegge
2014-09-02 18:25 ` Stefan Monnier
2014-09-02 20:56   ` Jan D.
2014-09-03  0:06     ` Stefan Monnier
2014-09-03  5:02       ` Jan Djärv
2014-09-03  9:53     ` Christoph Ruegge
2014-09-03 18:40       ` Jan Djärv
2014-09-03 18:51         ` Christoph Ruegge
2014-09-04  5:40           ` Jan Djärv

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).