GNU bug report logs - #17691
24.3.91; crash closing remote frame

Previous Next

Full log

Message #57 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.