all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jorgen Schaefer <forcer@forcix.cx>
To: emacs-devel@gnu.org
Subject: Re: Strange Emacs "hiccup" bug
Date: Fri, 23 May 2014 16:22:32 +0200	[thread overview]
Message-ID: <20140523162232.6939beae@forcix.jorgenschaefer.de> (raw)
In-Reply-To: <20140510221351.31049497@forcix.jorgenschaefer.de>

Some update on this bug, as I was able to reproduce it *temporarily*.

On Sat, 10 May 2014 22:13:51 +0200
Jorgen Schaefer <forcer@forcix.cx> wrote:

> At some point, apparently after some time of continuous use, Emacs
> starts to pause intermittently. It stops responding to keys or
> redisplaying for half a second, then it goes on. It does not matter
> which mode or buffer is in use.

This weird seemingly unrelated behavior is probably because I use a lot
of processes, both for flyspell and Python interaction and RPC calls.
The problem can occur when one of the processes dies.

I have been able to return Emacs to usable behavior multiple times
after such incidents happen by killing some idle processes, and they all
exhibit the same behavior:

A process dies (for example, when its buffer gets killed), but Emacs
does not forget it. It will show up in the process list, without an
associated buffer, and Emacs will be stuck in a tight loop trying to
read from these processes without success:

> 21:24:00.948071 pselect6(12, [3 4 9 11], [], NULL, {0, 1376013},
>                 {NULL, 8}) = 2 (in [9 11], left {0, 1373467})
>                 <0.000011>
> 21:24:00.948529 read(9, "", 4096)       = 0 <0.000009>
> 21:24:00.948564 read(11, "", 4096)      = 0 <0.000008>

I have been able to reproduce this behavior *sometimes* using the
following snippet:

(with-temp-buffer
  (let ((process-connection-type nil))
    (set-process-query-on-exit-flag
     (start-process "cat" (current-buffer) "cat")
     nil)))

I.e. create a buffer, associate a process with it, remove the query on
exit flag, and kill the buffer. The process stays around in the process
list and the process will remain in "ps" as a zombie.

The `process-connection-type' nil is the relevant part. With t, it
works correctly.

Now the weird part: This bug does not happen in a new copy of Emacs.
But when I have Emacs running for a while, suddenly the code snippet
above triggers the bug reliably.

After a while, Emacs catches up with itself, cleans up the zombie
processes, and the code above does not trigger the bug anymore. Until,
a random while later, it suddenly does again.

I have seen this happen in 24.3.50, 24.3.91 (pretest 2), and current
trunk.

Any ideas what might be happening here?

Regards,
Jorgen



  reply	other threads:[~2014-05-23 14:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-10 20:13 Strange Emacs "hiccup" bug Jorgen Schaefer
2014-05-23 14:22 ` Jorgen Schaefer [this message]
2014-05-23 15:37   ` Stefan Monnier
2014-05-23 16:12     ` Jorgen Schaefer

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

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

  git send-email \
    --in-reply-to=20140523162232.6939beae@forcix.jorgenschaefer.de \
    --to=forcer@forcix.cx \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.