GNU bug report logs - #79116
31.0.50; Crash on IGC build

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: spd <at> toadstyle.org, Eli Zaretskii <eliz <at> gnu.org>, 79116 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: bug#79116: 31.0.50; Crash on IGC build
Date: Thu, 31 Jul 2025 12:07:29 +0200

Helmut Eller <eller.helmut <at> gmail.com> writes:

> On Wed, Jul 30 2025, Eli Zaretskii wrote:
>
>> You seem to be talking about the data structures manipulated by the
>> display engine, but the thread which got hit with SIGABRT was not the
>> main thread (which indeed was in redisplay), it's some other thread.
>> And I wonder how come that other thread called MPS.
>
> I think that's the usual way how page faults are handled on MacOS:
>
>   1. the main thread hits a memory barrier (in this case in redisplay)
>
>   2. the Mach kernel stops the main thread and sends an message to
>      process' exception port
>
>   3. there is a dedicated thread that reads the message from the
>      exception port.  It's this thread that calls into MPS and
>      copies/scans objects as needed.  In this case that triggered the
>      assertion.
>
> I'm not sure when or how the main thread is resumed. Gerd would
> certainly know.

I'm not reading emacs-bugs normally, feel free to CC me, if there is
something I can help with.)

The barrier on macOS is a Match port. A port is a message queue olus a
thread handling messages. When a barrier is the oS stops the thread
hitting the barrier, and send the exception handler a message. The
thread of the exception does its MPS things, and tells the OS to resume
the thread having the problem.

BTW, glyph pools are only used for tty frames. Don't know if that plays
a role here.

Previous Next

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