unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@permabit.com>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: 17691 <17691@debbugs.gnu.org>
Subject: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 12 Jun 2014 17:14:39 -0400	[thread overview]
Message-ID: <CAJJWxE85UCNvAQ3Gx6N_k-C12fF34LPzMFdw6WUQQv4L7-QZ6g@mail.gmail.com> (raw)
In-Reply-To: <CAJJWxE-8h4gqHV+c5urWNLSNW1k4igMCOncsubgYWfXHSWVTjg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3291 bytes --]

  reply	other threads:[~2014-06-12 21:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 17:09 bug#17691: 24.3.91; crash closing remote frame Ken Raeburn
2014-06-04 17:34 ` Ken Raeburn
2014-06-04 17:36   ` Ken Raeburn
2014-06-04 17:39 ` Dmitry Antipov
2014-06-04 21:38   ` Ken Raeburn
2014-06-04 21:49     ` Ken Raeburn
2014-06-05  4:53       ` Dmitry Antipov
2014-06-05  5:56         ` Dmitry Antipov
2014-06-05 19:47         ` Ken Raeburn
2014-06-05 21:09           ` Ken Raeburn
2014-06-12 21:14             ` Ken Raeburn [this message]
2014-06-13  6:05               ` Eli Zaretskii
2014-06-13 21:37                 ` Ken Raeburn
2014-06-18 22:00 ` Paul Eggert
2014-06-21  2:52   ` Ken Raeburn
2014-06-21 18:21     ` Paul Eggert
2014-06-22  7:03       ` Ken Raeburn
2014-06-22 19:14         ` Paul Eggert
2014-08-02 21:34           ` Paul Eggert
2014-08-07  5:06             ` Ken Raeburn
2014-08-07  5:23               ` Paul Eggert
2014-08-07  6:02                 ` Ken Raeburn
2014-08-07 12:26                   ` Stefan Monnier
2014-08-07 14:36                     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJJWxE85UCNvAQ3Gx6N_k-C12fF34LPzMFdw6WUQQv4L7-QZ6g@mail.gmail.com \
    --to=raeburn@permabit.com \
    --cc=17691@debbugs.gnu.org \
    --cc=dmantipov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).