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: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 75275 <at> debbugs.gnu.org
Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 2 Jan 2025 01:58:09 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 75275 <at> debbugs.gnu.org
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Thu, 2 Jan 2025 00:47:06 -0600
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> > Stefan Kangas <stefankangas <at> gmail.com> writes:
>> >
>> >> I have run into a bug with make-thread on macOS 15.2, running on an M2.
>> >>
>> >> I can reproduce the issue consistently both on emacs-30 and master by
>> >> evaluating this in emacs -Q:
>> >>
>> >>     (make-thread (lambda () (sleep-for 1)) "bug")
>> >>
>> >> This leads to Emacs freezing up completely within a fraction of a
>> >> second.  I have time to move point once or maybe twice before it gets
>> >> non-responsive, let's say within a few tenths of a second.
>> >
>> > Curious question: Do you see a beach ball?
>>
>> Yes, I do see a beach ball.  It takes a second or so to show up, which I
>> guess is expected.
>>
>> >> When I kill the process in the lldb window with Ctrl+C, I can get the
>> >> following (this is on emacs-30):
>> >>
>> >>     frame #12: 0x0000000100403fec emacs`-[EmacsApp
>> >> run](self=0x0000000156610fe0, _cmd="run") at nsterm.m:5938:7
>> >>     frame #13: 0x00000001004024b0 emacs`ns_select_1(nfds=0,
>> >> readfds=0x00000001708c26bc, writefds=0x00000001708c263c,
>> >> exceptfds=0x0000000000000000, timeout=0x00000001708c2610,
>> >> sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4954:3
>> >>     frame #14: 0x000000010040202c emacs`ns_select(nfds=0,
>> >> readfds=0x00000001708c26bc, writefds=0x00000001708c263c,
>> >> exceptfds=0x0000000000000000, timeout=0x00000001708c2610,
>> >> sigmask=0x0000000000000000) at nsterm.m:5006:10
>> >
>> > I'm asking because of bug#72496. The part of the backtrace above reminds
>> > me a bit of what I trued to describe in that bug: EmacsApp.run never
>> > returning to ns_select_1. Can you see if it ever returns?
>>
>> After recompiling with NSTRACE_ENABLED, and based on reading at the
>> terminal output, it seems like it does not return to ns_select_1 after
>> the first line that reads
>>
>>     nextEventMatchingMask should only be called from the Main Thread!
>>
>> Is there a better way to see if it returns to that function?
>
> Who calls nextEventMatchingMask?  I don't see it in the backtraces you
> posted.

I believe the below two lines are relevant, but note that the function
in that case is actually called "_nextEventMatchingEventMask".  IOW, I
had assumed that "nextEventMatchingMask" is just what the error message
(perhaps confusingly) said:

2   AppKit 0x0000000192721c24 -[NSApplication(NSEventRouting)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3072
3   AppKit 0x0000000191db0060 -[NSApplication run] + 480

Previous Next

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