bug#17691: 24.3.91; crash closing remote frame

[Ken Raeburn]

On Jun 18, 2014, at 18:00, Paul Eggert <eggert@cs.ucla.edu> wrote:

>> In this process, fd 20 is the dropped TCP connection for the remote
>> display, and fd 7 is the unix-domain socket to the local display. Since the
>> remote connection is closed, pselect6 returns immediately, but we never
>> drop it from the fd set.
> 
> I tried to reproduce the problem on Fedora 20 x86-64, using your recipe and 
> the Emacs-24 branch, but could not.  Perhaps it's something to do with the 
> other stuff you're running, or it could be that I haven't applied Dmitry's 
> patch.

Specifying "lucid" toolkit?

I'm using 24.3.91 as packaged up for ftp, not the current emacs-24 branch. And 
without Dmitry's change, I couldn't close out the second display without losing 
Emacs completely; I'm surprised you don't see it.

I'm using the automatic desktop restoration, so it restores one or more windows 
on startup; I can't think off the top of my head what else would affect the 
displays much. Oh, I also tweaked some faces to display things in reduced size 
(mode lines, certain buffers' contents), which I imagine might cause more font 
lookup requests or something.

> 
> Anyway, this latest problem looks related to Bug#17647 and Bug#17805. Can you 
> easily reproduce the problem?  Does the patch proposed in Bug#17805 Message 
> #8 fix it?  Here's a URL:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=8;filename=17805.diff;att=1;bug=17805

This doesn't seem to make a difference. When I kill the ssh session over which 
I'm displaying one of the Emacs X11 windows, the Emacs process still goes to 
100% CPU utilization, and lots of garbage collection when I type.


I've done a few more experiments and found a few interesting things:

Some issues in my own configuration: An auto-save-hook that triggered desktop 
code that would allocate stuff. A 60-second repeating timer that ran uncompiled 
code in lots of buffers.

In Emacs: Since Emacs keeps looping polling the socket with the closed X11 
session, and the loop in keyboard.c includes a call to timer_check, it's 
calling timer_check a lot, and that function always copies the current 
timer-list sequence and sometimes the idle timers too. After I'd disabled some 
timers, and did some instrumentation under gdb, I found that timer_check would 
be called around 22000 times in the space of about 15 seconds -- over 1000 
times a second -- and that's with gdb breakpoints getting triggered on every 
call.

In another Emacs process, after I've cleaned up some stuff, once I set up the 
lost X11 session to trigger this busy loop, it looks like timer_check causes 
consing_since_gc to keep growing, but garbage collection doesn't actually 
happen until either a timer fires (causing call1 to be invoked on the timer 
handler function, which triggers a maybe_gc call) or I type a key or cause 
another input event (command_loop_1 invokes pre-command-hooks via 
safe_run_hooks which indirectly calls call0 and thus maybe_gc). In one 
instance, consing_since_gc got up to 3833040 before a timer fired, but 
gc_cons_threshold was 800000 and gc_relative_threshold was 3098800, so 
maybe_gc, had it been invoked, would've run GC before that point.

This wouldn't really be an issue if not for the busy loop while waiting for 
input.

Also, opening and closing tty frames don't trigger the problem, only X11 frames.

Ken