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

Previous Next

Full log

Message #51 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: Fri, 20 Jun 2014 22:52:57 -0400

On Jun 18, 2014, at 18:00, Paul Eggert <eggert <at> 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

Previous Next

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