[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17691: 24.3.91; crash closing remote frame
From: |
Ken Raeburn |
Subject: |
bug#17691: 24.3.91; crash closing remote frame |
Date: |
Sun, 22 Jun 2014 03:03:49 -0400 |
On Jun 21, 2014, at 14:21, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Ken Raeburn wrote:
>> Specifying "lucid" toolkit?
>
> I think so. I've discarded that test now and anyway am away from the desktop
> where I tested it, so I'm not sure.
Ah, my mistake, sorry... I'm mis-remembering the failure modes. The crash on
close came from a bug in font handling that was somehow dependent on the fonts
I was using. Between that and my init file at work...
I started a new experiment from scratch -- rebuilt from source on a new
GNU/Linux box, using an account with no Emacs init files, two ssh sessions into
the machine both forwarding X11 connections (from a Mac with a few X resources
loaded but no font specified). Started "emacs" or "emacs -Q" (I tried both
ways) in one session, invoked server-start, then in the other ssh session, ran
emacsclient -c -n, and after the window popped up, killed the ssh session with
"~.", and Emacs went to 100% CPU utilization. If I set
garbage-collection-messages to t, I would get the messages frequently. The only
timers visible to Lisp are two idle timers, for jit-lock and cursor blinking.
This happens with 24.3.91, both with and without Dmitry's patch. So,
technically, this busy loop is a different bug from the crash that started this
report, though both are caused by losing X11 connections. (Let me know if you'd
rather I open a new bug report on just this busy-loop problem.)
Closing the window via the window manager, instead of killing the TCP
connection, doesn't result in excessive CPU use.
I tried switching to the emacs-24 branch. I've already got a git mirror on that
machine, so I built from the sources as of this commit:
Author: Glenn Morris <rgm@gnu.org>
Date: Sat Jun 21 14:36:44 2014 -0700
* landmark.el: Commentary fixes.
I ran configured with --with-x-toolkit=lucid and a prefix, bootstrapped, emacs
-Q, etc., as above, and Emacs again went to 100% CPU utilization.
I've looked at the emacs-24 branch code around connection shutdown a little
more. If I use the window manager to get rid of a window, that's sending a
message through Emacs and it's deleting a frame and (for the last window on the
display) calling XtCloseDisplay and so on, by way of x_delete_frame in xterm.c.
If the connection is lost, instead, then x_connection_closed clears
dpyinfo->display, so x_delete_frame has no connection handle to pass to
XtCloseDisplay, and it has no file descriptor number to pass to
delete_keyboard_wait_descriptor.
As a test, I put a quick hack into x_connection_closed to call
delete_keyboard_wait_descriptor() on the file descriptor associated with the
lost connection, and it stopped the spinning from happening, but of course it
still doesn't do any of the Xt cleanup.
Paul, if my test recipe works for you without causing the excess CPU use, maybe
for you it's managing to call delete_keyboard_wait_descriptor on some path that
it's not getting to for me, for some reason?
Ken
- bug#17691: 24.3.91; crash closing remote frame, (continued)
- bug#17691: 24.3.91; crash closing remote frame, Dmitry Antipov, 2014/06/05
- bug#17691: 24.3.91; crash closing remote frame, Dmitry Antipov, 2014/06/05
- bug#17691: 24.3.91; crash closing remote frame, Ken Raeburn, 2014/06/05
- bug#17691: 24.3.91; crash closing remote frame, Ken Raeburn, 2014/06/05
- bug#17691: 24.3.91; crash closing remote frame, Ken Raeburn, 2014/06/12
- bug#17691: 24.3.91; crash closing remote frame, Eli Zaretskii, 2014/06/13
- bug#17691: 24.3.91; crash closing remote frame, Ken Raeburn, 2014/06/13
bug#17691: 24.3.91; crash closing remote frame, Paul Eggert, 2014/06/18