GNU bug report logs - #38748
28.0.50; crash on MacOS 10.15.2

Previous Next

Package: emacs;

Reported by: Andrii Kolomoiets <andreyk.mad <at> gmail.com>

Date: Thu, 26 Dec 2019 09:49:01 UTC

Severity: normal

Merged with 38822

Found in versions 27.0.60, 28.0.50

Fixed in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, andreyk.mad <at> gmail.com, alan <at> idiocy.org, jguenther <at> gmail.com, 38748 <at> debbugs.gnu.org
Subject: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Wed, 8 Jan 2020 20:39:43 +0000
On Wed, Jan 8, 2020 at 7:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Yes. Iʼll note that when this happens there are over 9000 stackframes,
> > > so perhaps itʼs stack exhaustion. macOS has a default stack of 8192
> > > kB, Iʼll see if increasing it helps.
> > That does sound like infinite recursion, or infinite recursion waiting
> > for something to change asynchronously that breaks the loop.
> No, GC is known to take many thousands of recursive calls to
> mark_object.  9000 is not a particularly high number, and doesn't
> necessarily signal infinite recursion.

In general, you're absolutely correct. But in this case, it still
sounds very likely: infinite recursion of a properly tail-recursive
function would loop rather than cause a stack overflow, which would
explain everything, except for why it's not actually an infinite loop;
I suspect the macOS code somewhere does modify things asynchronously.




This bug report was last modified 4 years and 300 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.