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: Robert Pluim <rpluim <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: alan <at> idiocy.org, jguenther <at> gmail.com, Andrii Kolomoiets <andreyk.mad <at> gmail.com>, 38748 <at> debbugs.gnu.org
Subject: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Wed, 08 Jan 2020 22:43:30 +0100
[Message part 1 (text/plain, inline)]
>>>>> On Wed, 8 Jan 2020 19:18:15 +0000, Pip Cet <pipcet <at> gmail.com> said:

    Pip> 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.

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

gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Iʼve attached the disassembly of the two versions. They're very very
similar (this is with -g3 -O0).

    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?

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

The allocation of inherited_attrs is the same in both.

    >> 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.

    Pip> That does sound like infinite recursion, or infinite recursion waiting
    Pip> for something to change asynchronously that breaks the loop. If the
    Pip> "ok = false" prevents the compiler from recognizing
    Pip> face_inherited_attr is effectively tail-recursive, that might be it?

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

Hmm, yes. Iʼll try that.

BTW, running under lldb, last_marked can be accessed successfully, but
of course under lldb you donʼt get all the nice commands from
.gdbinit. Iʼd build a newer version of gdb, but signing binaries on
macOS is a real hassle.

Robert

[modified.txt (text/plain, attachment)]
[unmodified.txt (text/plain, attachment)]

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

Previous Next


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