GNU bug report logs -
#19494
25.0.50; infinite loop in readable_event on master branch
Previous Next
Reported by: Noah Friedman <noah <at> splode.com>
Date: Sat, 3 Jan 2015 04:24:02 UTC
Severity: normal
Tags: moreinfo
Found in version 25.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19494 in the body.
You can then email your comments to 19494 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
eliz <at> gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Sat, 03 Jan 2015 04:24:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Noah Friedman <noah <at> splode.com>
:
New bug report received and forwarded. Copy sent to
eliz <at> gnu.org, bug-gnu-emacs <at> gnu.org
.
(Sat, 03 Jan 2015 04:24:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Sat, 03 Jan 2015 08:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 19494 <at> debbugs.gnu.org (full text, mbox):
> Cc: eliz <at> gnu.org
> From: Noah Friedman <friedman <at> splode.com>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Wed, 07 Jan 2015 21:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 19494 <at> debbugs.gnu.org (full text, mbox):
>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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Tue, 13 Jul 2021 18:07:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 19494 <at> debbugs.gnu.org (full text, mbox):
Noah Friedman <friedman <at> splode.com> writes:
>>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.
This was six years ago -- are you still seeing this issue in more recent
Emacs versions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 13 Jul 2021 18:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Tue, 20 Jul 2021 08:48:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 19494 <at> debbugs.gnu.org (full text, mbox):
I'll have to go dig around and get back to you; I've forgotten the context and what I might have done about it.
*From: *Lars Ingebrigtsen <larsi <at> gnus.org>
*To: *Noah Friedman <friedman <at> splode.com>
*CC: *eliz <at> gnu.org; 19494 <at> debbugs.gnu.org
*Date: *Jul 13, 2021 11:06:36
*Subject: *Re: bug#19494: 25.0.50; infinite loop in readable_event on master branch
> Noah Friedman <friedman <at> splode.com> writes:
>
>>> 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.
>
> This was six years ago -- are you still seeing this issue in more recent
> Emacs versions?
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Thu, 19 Aug 2021 13:22:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 19494 <at> debbugs.gnu.org (full text, mbox):
Noah Friedman <noah <at> splode.com> writes:
> I'll have to go dig around and get back to you; I've forgotten the
> context and what I might have done about it.
This was a month ago -- any progress? :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Fri, 27 Aug 2021 20:40:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 19494 <at> debbugs.gnu.org (full text, mbox):
I don't remember running into that particular behavior in the past year,
but in any case I see that quite a bit of the input event code has changed
since I reported this. So if I ever come across it again I would file a
new bug. Please close this one.
Thanks.
In <87y28x7ep8.fsf <at> gnus.org> 2021-08-19 15:21:23+0200, Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>Noah Friedman <noah <at> splode.com> writes:
>
>> I'll have to go dig around and get back to you; I've forgotten the
>> context and what I might have done about it.
>
>This was a month ago -- any progress? :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19494
; Package
emacs
.
(Sat, 28 Aug 2021 15:08:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 19494 <at> debbugs.gnu.org (full text, mbox):
Noah Friedman <friedman <at> splode.com> writes:
> I don't remember running into that particular behavior in the past year,
> but in any case I see that quite a bit of the input event code has changed
> since I reported this. So if I ever come across it again I would file a
> new bug. Please close this one.
OK; done.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
19494 <at> debbugs.gnu.org and Noah Friedman <noah <at> splode.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 28 Aug 2021 15:09:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 26 Sep 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 293 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.