GNU bug report logs -
#30322
Emacs 26 seems to have entered an infinite loop during GC on macOS
Previous Next
Reported by: John Wiegley <johnw <at> newartisans.com>
Date: Thu, 1 Feb 2018 20:22:01 UTC
Severity: normal
Merged with 30387
Found in version 26.0.91
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 30322 in the body.
You can then email your comments to 30322 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30322
; Package
emacs
.
(Thu, 01 Feb 2018 20:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
John Wiegley <johnw <at> newartisans.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 01 Feb 2018 20:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Eli,
I was writing an e-mail to a colleague today when my Emacs window completely froze up, taking 100% CPU constantly. Since it's still in that state now, I decided to fire up the stochastic profiler to see what it's doing. I've attached the screenshot.
It claims to be spending all its time in `lisp_align_free', behaving as if there's a CPU busy loop now taking place inside that function. Since very little time is being assigned to its callees, I believe an infinite loop has occurred here:
int i = 0;
bool aligned = busy;
struct ablock **tem = &free_ablock;
struct ablock *atop = &abase->blocks[aligned ? ABLOCKS_SIZE : ABLOCKS_SIZE - 1];
while (*tem)
{
if (*tem >= (struct ablock *) abase && *tem < atop)
{
i++;
*tem = (*tem)->x.next_free;
}
else
tem = &(*tem)->x.next_free;
}
I would like to suggest that before entering this loop, we record the initial value of *tem, and if we encounter again (or if we encounter it again X number of times), we report a non-fatal error and exit this function. That way I could save my work and restart Emacs.
I've noticed such a "lock up until I force quit" happening before, but it's very rare. Maybe a few times a year?
John
[Screen Shot 2018-02-01 at 12.03.14 PM.png (image/png, attachment)]
Merged 30322 30387.
Request was from
Noam Postavsky <npostavs <at> users.sourceforge.net>
to
control <at> debbugs.gnu.org
.
(Thu, 08 Feb 2018 12:22:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30322
; Package
emacs
.
(Wed, 09 Oct 2019 21:34:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 30322 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <johnw <at> newartisans.com> writes:
> I was writing an e-mail to a colleague today when my Emacs window
> completely froze up, taking 100% CPU constantly. Since it's still in
> that state now, I decided to fire up the stochastic profiler to see
> what it's doing. I've attached the screenshot.
>
> It claims to be spending all its time in `lisp_align_free', behaving
> as if there's a CPU busy loop now taking place inside that
> function. Since very little time is being assigned to its callees, I
> believe an infinite loop has occurred here:
This was a year ago -- are you still seeing these hangs in Emacs 27?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30322
; Package
emacs
.
(Sun, 16 Aug 2020 16:51:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 30322 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> John Wiegley <johnw <at> newartisans.com> writes:
>
>> I was writing an e-mail to a colleague today when my Emacs window
>> completely froze up, taking 100% CPU constantly. Since it's still in
>> that state now, I decided to fire up the stochastic profiler to see
>> what it's doing. I've attached the screenshot.
>>
>> It claims to be spending all its time in `lisp_align_free', behaving
>> as if there's a CPU busy loop now taking place inside that
>> function. Since very little time is being assigned to its callees, I
>> believe an infinite loop has occurred here:
>
> This was a year ago -- are you still seeing these hangs in Emacs 27?
More information was requested, but no response was given within a few
months, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
30322 <at> debbugs.gnu.org and John Wiegley <johnw <at> newartisans.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 16 Aug 2020 16:51: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
.
(Mon, 14 Sep 2020 11:24:05 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Moritz Schäfer <moritz.schaefer <at> biol.ethz.ch>
to
control <at> debbugs.gnu.org
.
(Tue, 10 Nov 2020 21:34:01 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, 13 Dec 2020 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 203 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.