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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrii Kolomoiets <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 19:18:15 +0000

On Wed, Jan 8, 2020 at 5:40 PM Robert Pluim <rpluim <at> gmail.com> wrote:
>     >> But I found the commit after which error is occurs:>     >> b2949d39261e82c33572ba8a250298ef0b165b95
>     >>
>     >> Commenting out that 'ok = false;' line make Emacs works without errors.
>
> I can confirm this.

I think we should disassemble the two versions and see where the
differences are, unless this is too difficult because of inlining. Can
you provide compiler details?

>     Eli> I cannot explain how that change could cause any harm.  Here's the
>     Eli> relevant code fragment:

>     Eli> So how could the initial value of 'ok' matter here?  What am I
>     Eli> missing?

I think it's likely to be the stack thing; the ok = false might make
the difference between allocating inherited_attrs on the stack once
and doing so once per recursion of face_inherited_attr. The latter
case might lead to a stack overflow more easily.

> 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. If the
"ok = false" prevents the compiler from recognizing
face_inherited_attr is effectively tail-recursive, that might be it?

Changing the line to "ok = true" would be an interesting experiment.

Previous Next

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