From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#17691: 24.3.91; crash closing remote frame Date: Fri, 20 Jun 2014 22:52:57 -0400 Message-ID: <9CAB2038-8C9D-4119-8315-B3E574F72D89@permabit.com> References: <53A20C0F.20206@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1403319265 24234 80.91.229.3 (21 Jun 2014 02:54:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2014 02:54:25 +0000 (UTC) Cc: 17691@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 21 04:54:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WyBRb-0002tF-2v for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jun 2014 04:54:19 +0200 Original-Received: from localhost ([::1]:43590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyBRa-0007IL-Lt for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jun 2014 22:54:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyBRT-0007HH-BI for bug-gnu-emacs@gnu.org; Fri, 20 Jun 2014 22:54:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WyBRL-0007Nc-AQ for bug-gnu-emacs@gnu.org; Fri, 20 Jun 2014 22:54:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyBRL-0007NX-4p for bug-gnu-emacs@gnu.org; Fri, 20 Jun 2014 22:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WyBRK-0000U1-Il for bug-gnu-emacs@gnu.org; Fri, 20 Jun 2014 22:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Jun 2014 02:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17691 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 17691-submit@debbugs.gnu.org id=B17691.14033191901769 (code B ref 17691); Sat, 21 Jun 2014 02:54:02 +0000 Original-Received: (at 17691) by debbugs.gnu.org; 21 Jun 2014 02:53:10 +0000 Original-Received: from localhost ([127.0.0.1]:55306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WyBQT-0000SQ-O7 for submit@debbugs.gnu.org; Fri, 20 Jun 2014 22:53:10 -0400 Original-Received: from mail-qg0-f49.google.com ([209.85.192.49]:39570) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WyBQQ-0000Ru-Ts for 17691@debbugs.gnu.org; Fri, 20 Jun 2014 22:53:08 -0400 Original-Received: by mail-qg0-f49.google.com with SMTP id f51so4106454qge.8 for <17691@debbugs.gnu.org>; Fri, 20 Jun 2014 19:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JSCMQwQc/g2mO7pWtgIAR4Xwzj5uIDYbrqmEOSB+n48=; b=LHBIqLUhlnT3AuhbcBDop9KE+nw29taPVv2+hVuNr1xZ1C119ffV/tLrJLNEZ1xl6N 8ZiT4sH6D7d338mXdv5yX7HczFPlu6yag08NEA3XbA405UCyVFD3RUwWr98yPnvbe4/K WJyOQiS59eQhf9sz3qi7lZApQoXCZjE4fkorM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JSCMQwQc/g2mO7pWtgIAR4Xwzj5uIDYbrqmEOSB+n48=; b=k7zGdDcu3hdjC8gK+hDPtb1EmcLlABb6MIPeh2CduYf/34nNOjLQ/Srvozu8XoZuGF VDoCAsRmZ0elA27KpDb/pJjwpGaHgrvKuvxSTWeU8/yFQwxsX00y1PS2tNKJAt/OlAI3 yoJPOQYAd+IREWhTgUgI+b1krxl/MC3nKyz9ctnlBKwiMrUU553r47TDdm19VBY4uHSE q19XmQ5rH3BcT5pxHOY1Z3BsF3/J0m5BvOnY3GNPXk6CB6qLSrB18J4SRiCFrK/dlD9X lNm/ddcKi2wcZ/aMzmDYgg+EN0sI2dQUUz3G8+Z/88Or925jlJuIyxD5mTpTa85jPKyf Si7w== X-Gm-Message-State: ALoCoQmeV3M57prCK9TKplMshDxgGcEkjbrD7vBH9QQ0EerazbvoXffvdovd2wiWbP8RJZmXrs14 X-Received: by 10.224.72.13 with SMTP id k13mr10816399qaj.54.1403319181387; Fri, 20 Jun 2014 19:53:01 -0700 (PDT) Original-Received: from [10.1.12.46] (vpn.permabit.com. [66.202.84.2]) by mx.google.com with ESMTPSA id l10sm16811792qae.41.2014.06.20.19.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 19:53:00 -0700 (PDT) In-Reply-To: <53A20C0F.20206@cs.ucla.edu> X-Mailer: Apple Mail (2.1878.2) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90621 Archived-At: On Jun 18, 2014, at 18:00, Paul Eggert 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. >=20 > 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. >=20 > 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: >=20 > = http://debbugs.gnu.org/cgi/bugreport.cgi?msg=3D8;filename=3D17805.diff;att= =3D1;bug=3D17805 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=