Received: (at 19494) by debbugs.gnu.org; 7 Jan 2015 21:08:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 16:08:52 2015 Received: from localhost ([127.0.0.1]:39556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Y8xqW-0003LS-9f for submit <at> debbugs.gnu.org; Wed, 07 Jan 2015 16:08:52 -0500 Received: from bacon-event-horizon.splode.com ([74.207.245.10]:33484 helo=splode.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <friedman@HIDDEN>) id 1Y8xqU-0003LI-4n for 19494 <at> debbugs.gnu.org; Wed, 07 Jan 2015 16:08:51 -0500 Received: from unexploded-cow.prv.splode.com (prv.splode.com [173.8.128.9]) (authenticated bits=0) by splode.com (8.14.8/8.14.8) with ESMTP id t07L8mLD032390 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Jan 2015 13:08:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Noah Friedman <friedman@HIDDEN> To: eliz@HIDDEN Subject: Re: bug#19494: 25.0.50; infinite loop in readable_event on master branch In-Reply-To: <83oaqg9t1z.fsf@HIDDEN> (eliz@HIDDEN Saturday, 03 Jan 15 10:17:44 +0200) References: <20150102191803.251212.FMU1084@HIDDEN> <83oaqg9t1z.fsf@HIDDEN> Date: Wed, 07 Jan 2015 13:08:48 -0800 (PST) Message-Id: <20150107130848.139696.FMU1084@HIDDEN> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (splode.com [74.207.245.10]); Wed, 07 Jan 2015 13:08:49 -0800 (PST) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19494 Cc: 19494 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Noah Friedman <friedman@HIDDEN> List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) >Why do you need that code, and in a timer on top of that? It looks >strangely, and probably papers over some bug, either one that existed >in the past or maybe even an existing one. If that bug still exists, >a bug report will be appreciated. It's very old code, circa 1995. Since it predates the v21 redisplay engine rewrite, I have no idea if it's still necessary; I'm testing that now. >One thing is clear: having input-pending-p return non-nil when there's >nothing in the queue but these buffer-switch events is a real bug that >causes quite a few problems. So going back is not an option, I >think. I concur. I don't want to revert it, it may just need some refinement.
bug-gnu-emacs@HIDDEN:bug#19494; Package emacs.
Full text available.
Received: (at 19494) by debbugs.gnu.org; 3 Jan 2015 08:17:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 03:17:50 2015
Received: from localhost ([127.0.0.1]:35377 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Y7JuA-0002YX-Bi
for submit <at> debbugs.gnu.org; Sat, 03 Jan 2015 03:17:50 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:57762)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <eliz@HIDDEN>) id 1Y7Ju7-0002YN-8H
for 19494 <at> debbugs.gnu.org; Sat, 03 Jan 2015 03:17:48 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
a-mtaout20.012.net.il (HyperSendmail v2007.08) id
<0NHL00800CTWUB00@HIDDEN> for 19494 <at> debbugs.gnu.org;
Sat, 03 Jan 2015 10:17:45 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
(HyperSendmail v2007.08) with ESMTPA id
<0NHL008AJDPKLV60@HIDDEN>;
Sat, 03 Jan 2015 10:17:45 +0200 (IST)
Date: Sat, 03 Jan 2015 10:17:44 +0200
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#19494: 25.0.50;
infinite loop in readable_event on master branch
In-reply-to: <20150102191803.251212.FMU1084@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Noah Friedman <noah@HIDDEN>
Message-id: <83oaqg9t1z.fsf@HIDDEN>
References: <20150102191803.251212.FMU1084@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 19494
Cc: 19494 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)
> Cc: eliz@HIDDEN
> From: Noah Friedman <friedman@HIDDEN>
> Date: Fri, 02 Jan 2015 19:18:03 -0800 (PST)
>
> That is, the entire kbd_buffer queue is BUFFER_SWITCH_EVENT events.
> Because of that, it means the sequence
>
> do {
> ....
> if (event == kbd_buffer + KBD_BUFFER_SIZE)
> event = kbd_buffer;
> }
> while (event != kbd_store_ptr);
>
> in the function readable_event will, at least at times, loop forever.
It's strange no one reported anything similar since that changeset was
pushed.
> I don't have a trivial or always-reliable test case but I think the
> offending elisp is the following, running in a (non-idle) timer:
>
> (force-mode-line-update 'all)
> (sit-for 0) ; force redisplay
>
> I can change the elisp in question since I wrote it, but I'm not sure what
> the right way to do it is since it's not just running during idle times.
Why do you need that code, and in a timer on top of that? It looks
strangely, and probably papers over some bug, either one that existed
in the past or maybe even an existing one. If that bug still exists,
a bug report will be appreciated.
> In any case having emacs lock up in a non-recoverable way seems like a bug,
> since the only way out is to hit C-g and abort, or else go in with gdb
> on the running process and force a return.
>
> Maybe this loop needs some kind of "didn't find any other event" flag to
> avoid looping, but I thought I'd check with the original committer first in
> case he has a better idea.
Stefan is in a better position to answer that, as my keyboard-event
foo is not strong enough. You will see in the archives that I asked
him whether we should ignore these events before writing the patch.
One thing is clear: having input-pending-p return non-nil when there's
nothing in the queue but these buffer-switch events is a real bug that
causes quite a few problems. So going back is not an option, I
think.
I do agree it would be nice to remove the possibility of looping, even
if it is a remote one. And the logic you suggest is exactly what I
had in mind reading your description, so no, I don't have any better
idea. Maybe Stefan does.
bug-gnu-emacs@HIDDEN:bug#19494; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Jan 2015 04:23:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 23:23:38 2015
Received: from localhost ([127.0.0.1]:35362 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Y7GFW-0005Nz-Eh
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2015 23:23:38 -0500
Received: from eggs.gnu.org ([208.118.235.92]:55785)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <friedman@HIDDEN>) id 1Y7GFU-0005Nr-AH
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2015 23:23:36 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <friedman@HIDDEN>) id 1Y7GFT-0001xg-5Q
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2015 23:23:36 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:35402)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <friedman@HIDDEN>) id 1Y7GFT-0001xc-0s
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2015 23:23:35 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57507)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <friedman@HIDDEN>) id 1Y7GFS-00025D-0Z
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2015 23:23:34 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <friedman@HIDDEN>) id 1Y7GFO-0001xH-Pa
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2015 23:23:33 -0500
Received: from [2600:3c01::f03c:91ff:fe96:f92b] (port=45237 helo=splode.com)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <friedman@HIDDEN>) id 1Y7GFO-0001wI-Hc
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2015 23:23:30 -0500
Received: from unexploded-cow.prv.splode.com (prv.splode.com [173.8.128.9])
(authenticated bits=0)
by splode.com (8.14.8/8.14.8) with ESMTP id t033I3ON004169
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO)
for <bug-gnu-emacs@HIDDEN>; Fri, 2 Jan 2015 19:18:03 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Noah Friedman <friedman@HIDDEN>
To: bug-gnu-emacs@HIDDEN
X-Debbugs-CC: eliz@HIDDEN
Subject: 25.0.50; infinite loop in readable_event on master branch
Date: Fri, 02 Jan 2015 19:18:03 -0800 (PST)
Message-Id: <20150102191803.251212.FMU1084@HIDDEN>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7
(splode.com [74.207.245.10]); Fri, 02 Jan 2015 19:18:04 -0800 (PST)
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Noah Friedman <noah@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)
Ever since commit 614beeecf29d16c08f66a4f82b6085be90df8a74 (c. Nov 01 2014)
I keep finding "idle" emacs processes running in a tight loop in
keyboard.c:readable_event after I come back to my session the following
morning. In those cases, kbd_buffer is full of the same event, in my case:
$17 = {
kind = BUFFER_SWITCH_EVENT,
part = scroll_bar_nowhere,
code = 0,
modifiers = 0,
x = 0,
y = 0,
timestamp = 0,
frame_or_window = 12962290,
arg = 12962290
}
That is, the entire kbd_buffer queue is BUFFER_SWITCH_EVENT events.
Because of that, it means the sequence
do {
....
if (event == kbd_buffer + KBD_BUFFER_SIZE)
event = kbd_buffer;
}
while (event != kbd_store_ptr);
in the function readable_event will, at least at times, loop forever.
I don't have a trivial or always-reliable test case but I think the
offending elisp is the following, running in a (non-idle) timer:
(force-mode-line-update 'all)
(sit-for 0) ; force redisplay
I can change the elisp in question since I wrote it, but I'm not sure what
the right way to do it is since it's not just running during idle times.
In any case having emacs lock up in a non-recoverable way seems like a bug,
since the only way out is to hit C-g and abort, or else go in with gdb
on the running process and force a return.
Maybe this loop needs some kind of "didn't find any other event" flag to
avoid looping, but I thought I'd check with the original committer first in
case he has a better idea.
Noah Friedman <noah@HIDDEN>:eliz@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.eliz@HIDDEN, bug-gnu-emacs@HIDDEN:bug#19494; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.