bug#17691: 24.3.91; crash closing remote frame

[Ken Raeburn]

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