Jeff Mincy <jeff(a)delphioutpost.com> writes:
On Fri, 7 Jun 2002, andy(a)xemacs.org wrote:
> I'm not sure what you expect to happen. Even if XEmacs is unmapped the X
> version is totally dependent on the X libraries / server working properly.
> I guess a crash would be better than a hard loop. Its not clear how this
> could be implemented though - XtAppPending does not return any useful
> information about a broken X connection.
Yes, I would prefer a crash. It is too easy for a looping program to
go unnoticed. And in a multi-user environment it is easy to annoy my
peers or sysadmins.
I think this problem occurs because of delete_device event handling.
The broken x connection causes the IO_error_handler to be called.
I've been annoyed by this problem for a while. I have it in my (very
long) queue to verify if this is the problem and propose a fix. If
somebody else wants to look at it though...
I attached part of a previous message on the issue....
The good news is that 21.4.8 seems to address the issue. At least the
one test I ran produced an error in another visible window. Xemacs
I was impressed.
Thanks to whoever was responsible for the fix.
I'll try testing further.
Date: Tue, 23 Apr 2002 22:34:55 -0400
Subject: Re: gnuclient *feature* -- crash when frames lose X connection
Cc: XEmacs Beta List <xemacs-beta(a)xemacs.org>
The function x_IO_error_handler enqueues a magic eval delete_device
event. Supposedly, doing this magic event will cause the device to exit.
After event is enqueued, the device is marked as being deleted.
x_IO_error_handler (Display *disp)
enqueue_magic_eval_event (io_error_delete_device, dev);
DEVICE_X_BEING_DELETED (d) = 1;
Fthrow (Qtop_level, Qnil);
Then we go over to handle_magic_event. The first thing that this code
does is checks to see if the frame is being deleted. If it is, magic
event function returns, and does not actually process the event.
Might this be the problem?
emacs_Xt_handle_magic_event (Lisp_Event *emacs_event)
/* This function can GC */
XEvent *event = &emacs_event->event.magic.underlying_x_event;
struct frame *f = XFRAME (EVENT_CHANNEL (emacs_event));
if (!FRAME_LIVE_P (f) || DEVICE_X_BEING_DELETED (XDEVICE (FRAME_DEVICE (f))))
>> Dear Bug Team!
>> When running "xemacs -unmapped -f gnuserver &" the xemacs process
>> survives the loss of the X server on which it was started. But it
>> falls into a hard loop in XtAppPending called from
>> emacs_Xt_event_pending_p. It proceeds to consume all available CPU
>> I've seen this problem on Linux and on Solaris.
>> The easiest way to reproduce this is to ssh with X forwarding to a
>> system running X. This could be as simple as "ssh -X localhost".
>> Then start xemacs with "xemacs -unmapped -f gnuserver &". Give it
>> moment to initialize, then kill the local ssh process. Then "top"
>> should indicate that xemacs is running 100% CPU.