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: Thu, 12 Jun 2014 17:14:39 -0400 Message-ID: References: <6ey4xca9g0.fsf@just-testing.permabit.com> <538F59EE.5020003@yandex.ru> <6evbsg1hkr.fsf@just-testing.permabit.com> <6er4341h15.fsf@just-testing.permabit.com> <538FF7BC.8020203@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d13947a0cbb04fbaa0c60 X-Trace: ger.gmane.org 1402607743 32008 80.91.229.3 (12 Jun 2014 21:15:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Jun 2014 21:15:43 +0000 (UTC) Cc: 17691 <17691@debbugs.gnu.org> To: Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 12 23:15:36 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 1WvCLP-0004gt-1v for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Jun 2014 23:15:35 +0200 Original-Received: from localhost ([::1]:55712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvCLO-0005PV-K2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Jun 2014 17:15:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvCKy-0004v5-MS for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2014 17:15:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvCKt-00054D-Im for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2014 17:15:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvCKt-00053v-GF for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2014 17:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WvCKs-0001rM-Nh for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2014 17:15: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: Thu, 12 Jun 2014 21:15: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: Original-Received: via spool by 17691-submit@debbugs.gnu.org id=B17691.14026076907105 (code B ref 17691); Thu, 12 Jun 2014 21:15:02 +0000 Original-Received: (at 17691) by debbugs.gnu.org; 12 Jun 2014 21:14:50 +0000 Original-Received: from localhost ([127.0.0.1]:45898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvCKf-0001qU-0Z for submit@debbugs.gnu.org; Thu, 12 Jun 2014 17:14:49 -0400 Original-Received: from mail-la0-f43.google.com ([209.85.215.43]:47076) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvCKb-0001qC-Cf for 17691@debbugs.gnu.org; Thu, 12 Jun 2014 17:14:46 -0400 Original-Received: by mail-la0-f43.google.com with SMTP id e16so985026lan.16 for <17691@debbugs.gnu.org>; Thu, 12 Jun 2014 14:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IaWdlXWvCaSUnxZ7ztvn1a1S4+0t20E1lBRSsC6M6/8=; b=SxRFd0nDtm7ySZKZvco+oEAKfvN63LeK+J3Fn/qgsAUnz5wxHCn9SreqFQ4n93L4Lj 3HjR8n0/x3rAY4t2TsPI4e2kBuMmXw/5wLuVMA7hXTxQ+oWGXFssFqVyEuOa0LifPIWS 01CxPMQ9Uq5t9+gh0UlHFgUdQX/JoJpe9cUY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IaWdlXWvCaSUnxZ7ztvn1a1S4+0t20E1lBRSsC6M6/8=; b=kDHUSnuGEC+rt/xaCk9zJsPD77vXYKR28j2yI8o08xIUGJMSxCJwdjhdQPCbZ9NPzn 4lU8i1CogMYn7NiTrP+706b6WQWGDuObOjWj4PcTJe+5BceWYXg8U6u5pdpl7pTA1UsE HsklnWrhfY08dA7tQnOJtDqMwqvs2WbJahAinMggVQbbw7ku5bUo3Uc/emkqkC4Baloh eWAoui2XIL+T7OmVd9WARslQB4xvaun7CCd9jSjx944RxCIIHzEWra/EPRrw/kny9ZTE Mr2vKs5fEru49jYOW4wOkpSIRmIuKZTxD8MdRViII5ZiThK2xDrb4iHbEVNgUh/+dLhI Nwcg== X-Gm-Message-State: ALoCoQlVL7FCQv9cMXVt+nha4p/y//S13R4O8hbHkkB4AWQJ/x7VHvOV9JoDI6dh90duOUkf2GnC X-Received: by 10.152.6.131 with SMTP id b3mr34483852laa.9.1402607679173; Thu, 12 Jun 2014 14:14:39 -0700 (PDT) Original-Received: by 10.112.9.74 with HTTP; Thu, 12 Jun 2014 14:14:39 -0700 (PDT) In-Reply-To: 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:90298 Archived-At: --089e013d13947a0cbb04fbaa0c60 Content-Type: text/plain; charset=UTF-8 I've noticed Emacs doing a lot of garbage collection after I've lost a remote network connection where I had an Emacs window displayed. (This is Emacs 24.3.91 with the changes from Dmitry; without the changes the lost connection would kill Emacs altogether.) Typically it seems to be GCing a few times in the span of a couple seconds or so, mostly after I've typed something. Each character seems to be enough to trigger it, so if I start typing a line of text, the "Garbage collecting..." messages are constantly flickering in the minibuffer. I eventually traced it back to lots of invocations of timer callbacks; while I'm still tracing down exactly why they're happening so much, I noticed that the CPU utilization of Emacs is hovering around 100% now. (It's sluggish but does still respond.) According to strace it seems to be constantly doing this, over and over: [pid 5736] 16:27:14.008209 clock_gettime(CLOCK_REALTIME, {1402604834, 8265741}) = 0 [pid 5736] 16:27:14.008428 pselect6(21, [7 8 10 11 12 13 16 18 20], [], NULL, {45, 991734259}, {NULL, 8}) = 1 (in [20], left {45, 991729436}) [pid 5736] 16:27:14.008666 poll([{fd=11, events=POLLIN}], 1, 0) = 0 (Timeout) [pid 5736] 16:27:14.008925 clock_gettime(CLOCK_REALTIME, {1402604834, 8985614}) = 0 [pid 5736] 16:27:14.009215 recvfrom(7, 0x3ef1ed4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) 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'm still trying to figure out if it's incorrectly firing an idle timer handler each time around a loop or something like that, which might account for the excessive garbage collection. My test method: 1) Start (modified) Emacs on :0 in daemon mode via emacsclient -c -a "" -n 2) Use ssh to log into the desktop again with a different $DISPLAY 3) Use emacsclient to get an X11 window popped up 4) Use "~." to kill the ssh session 5) Use top, strace, etc to look at the spinning Emacs process --089e013d13947a0cbb04fbaa0c60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= 9;ve noticed Emacs doing a lot of garbage collection after I've=C2=A0lost a remote network connection where= I had an Emacs window displayed. (This is Emacs 24.3.91 with the changes f= rom Dmitry; without the changes the lost connection would kill Emacs altoge= ther.) Typically it seems to be GCing a few times in the span of a couple s= econds or so, mostly after I've typed something. Each character seems t= o be enough to trigger it, so if I start typing a line of text, the "G= arbage collecting..." messages are constantly flickering in the minibu= ffer.

I eventuall= y traced it back to lots of invocations of timer=C2=A0callbacks; while I'm still tracing down exactly why t= hey're happening so much, I noticed that the CPU utilization of Emacs i= s hovering around 100% now. (It's sluggish but does still respond.) Acc= ording to strace it seems to be constantly doing this, over and over:

[pid =C2=A0= 5736] 16:27:14.008209 clock_gettime(CLOCK_REALTIME, {1402604834, 8265741}) = =3D 0
[pid =C2=A05736] 16:27:14.008428 psel= ect6(21, [7 8 10 11 12 13 16 18 20], [], NULL, {45, 991734259}, {NULL, 8}) = =3D 1 (in [20], left {45, 991729436})
[pid =C2=A05736] 16:27:14.008666 poll([{fd=3D11,= events=3DPOLLIN}], 1, 0) =3D 0 (Timeout)
[= pid =C2=A05736] 16:27:14.008925 clock_gettime(CLOCK_REALTIME, {1402604834, = 8985614}) =3D 0
[pid =C2=A05736] 16:27:14.009215 recvfrom(7, 0x3= ef1ed4, 4096, 0, 0, 0) =3D -1 EAGAIN (Resource temporarily unavailable)

In this=C2=A0process, fd 20 is the dropped TC= P 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'm sti= ll trying to figure out if it's incorrectly firing an idle timer handle= r each time around a loop or something=C2= =A0like that, which might account for the excessive garbage collecti= on.

My test=C2=A0method:
1) Start (modified) Emacs on :0 in daemon mode via emacsclient -c -a = "" -n
2) Use ssh to log into the desktop again with a<= span style=3D"white-space:pre">=C2=A0different $DISPLAY
3) Use emacsclient to get an X11 window=C2=A0popped up
4) Use "~." to kill the ssh session
5) Use top, strace, etc to look at the spinning=C2=A0Emacs process


<= /div>
--089e013d13947a0cbb04fbaa0c60--