GNU bug report logs - #75275
30.0.92; `make-thread` bug on macOS 15.2

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 75275 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 20:59:26 +0100

Alan Third <alan <at> idiocy.org> writes:

> On Thu, Jan 02, 2025 at 06:52:11PM +0100, Gerd Möllmann wrote:
>> >
>> > AFAIR my theory went like:
>> >
>> > - [NSApp run] + key event handler put C-g in the hold queue
>> >
>> > - ns_select_1 calls "run" (it did before my change).
>> >
>> > - I couldn't find how input events from the hold queue come
>> >   to Emacs in the whole process, so I added that
>> >
>> > - The "call run in all threads" was then a mistake
>> >
>> > Seemed to work, to a degree.
>> 
>> Maybe I should add that that is kind of a loop. It can be that the first
>> call to ns_select_1 has no C-g in the hold queue, NSApp.run leads to one
>> being put in the hold queue. A second ns_select_1 then finds C-g and
>> gives it Emacs and so on.
>> 
>> Why that whole thing hangs, is another question.
>
> I suspect it's because we removed the code in bug 65843.
>
> We removed that because there was a crash on start using a specific
> desktop file. Something to do with a certain amount of iconified
> frames or something. It never made much sense to me, but if the
> comment that went along with the code was right then sometimes the app
> defined event is never delivered and therefore the event loop doesn't
> stop.

That sounds a bit like the second category of freezes I've seen in the
past, the ones without beach ball, where Emacs apparently handles
Cocoa events, but no input events are transferred to keyboard.c.

I think the other category, the freezes with beach ball are older than
bug#65834. I've had them just from the start when using Emacs again.

> I can't believe that's a genuine bug in Apple's code, because surely
> they'd have fixed it by now, so probably it's something in our code,
> but who knows what.

I don't believe it's an Apple problem either, for the same reason.

> You could try reverting that change and see if it solves your hangs.
> If so then we'll have to find another solution, like perhaps just
> preventing ns_send_appdefined from doing anything while we're creating
> frames.

I'll pass. I've never found a reproducer for either category of freeze,
and now I've had enough, at least for some time :-).

Previous Next

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