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

Previous Next

Full log

Message #26 received at 75275 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Alan Third <alan <at> idiocy.org>, 
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75275 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 2 Jan 2025 01:31:39 -0600

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

> The above works as expected on MS-Windows and on GNU/Linux: after
> about 1 sec the new thread exits, and Emacs works normally.
> list-threads shows a single main thread running at that time.

Thanks for verifying that this is macOS specific.

>>   thread #7, name = 'bug'
>>     frame #0: 0x000000018de3a2b0
>> dyld`dyld3::MachOLoaded::findClosestSymbol(unsigned long long, char
>> const**, unsigned long long*) const + 488
>>     frame #1: 0x000000018de1b13c dyld`dyld4::APIs::dladdr(void const*,
>> dl_info*) + 236
>>     frame #2: 0x000000018e012f00 libsystem_c.dylib`backtrace_symbols + 144
>>     frame #3: 0x000000018f4998c0 Foundation`-[_NSCallStackArray
>> descriptionWithLocale:indent:] + 144
>>     frame #4: 0x000000018f3e8c10 Foundation`_NS_os_log_callback + 276
>>     frame #5: 0x000000018debee60
>> libsystem_trace.dylib`_os_log_fmt_flatten_NSCF + 64
>>     frame #6: 0x000000018dec5830
>> libsystem_trace.dylib`_os_log_fmt_flatten_object_impl + 372
>>     frame #7: 0x000000018debc9c8
>> libsystem_trace.dylib`_os_log_impl_flatten_and_send + 2144
>>     frame #8: 0x000000018debc150 libsystem_trace.dylib`_os_log + 168
>>     frame #9: 0x000000018debc0a0 libsystem_trace.dylib`_os_log_impl + 28
>>     frame #10: 0x000000019209151c AppKit`-[NSApplication reportException:] + 624
>>     frame #11: 0x0000000191db0118 AppKit`-[NSApplication run] + 664
>>     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
>>     frame #15: 0x000000010036930c
>> emacs`wait_reading_process_output(time_limit=1, nsecs=0, read_kbd=0,
>> do_display=false, wait_for_cell=(i = 0x0000000000000000),
>> wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5753:18
>>     frame #16: 0x000000010000b400 emacs`Fsleep_for(seconds=(i =
>> 0x0000000000000006), milliseconds=(i = 0x0000000000000000)) at
>> dispnew.c:6248:2
>
> This is the new Lisp thread started by make-thread, but it is
> somewhere in the bowels of macOS.  Is this what you see each time you
> kill Emacs after it hangs?

Yes, the backtrace seems to be the same every time.  For example, I
tried again just now and got this over three attempts:

1. thread #18, name = 'bug'
    frame #0: 0x000000018de3a268
dyld`dyld3::MachOLoaded::findClosestSymbol(unsigned long long, char
const**, unsigned long long*) const + 416
    frame #1: 0x000000018de1b13c dyld`dyld4::APIs::dladdr(void const*,
dl_info*) + 236
    frame #2: 0x000000018e012f00 libsystem_c.dylib`backtrace_symbols + 144
    frame #3: 0x000000018f4998c0 Foundation`-[_NSCallStackArray
descriptionWithLocale:indent:] + 144

2. thread #7, name = 'bug'
    frame #0: 0x000000018de3a2b0
dyld`dyld3::MachOLoaded::findClosestSymbol(unsigned long long, char
const**, unsigned long long*) const + 488
    frame #1: 0x000000018de1b13c dyld`dyld4::APIs::dladdr(void const*,
dl_info*) + 236
    frame #2: 0x000000018e012f00 libsystem_c.dylib`backtrace_symbols + 144
    frame #3: 0x000000018f4998c0 Foundation`-[_NSCallStackArray
descriptionWithLocale:indent:] + 144

3. thread #9, name = 'bug'
    frame #0: 0x000000018de3a268
dyld`dyld3::MachOLoaded::findClosestSymbol(unsigned long long, char
const**, unsigned long long*) const + 416
    frame #1: 0x000000018de1b13c dyld`dyld4::APIs::dladdr(void const*,
dl_info*) + 236
    frame #2: 0x000000018e012f00 libsystem_c.dylib`backtrace_symbols + 144
    frame #3: 0x000000018f4998c0 Foundation`-[_NSCallStackArray
descriptionWithLocale:indent:] + 144

> Can someone describe how sleep-for works on macOS, i.e. what is
> supposed to happen after ns_select_1 calls -[EmacsApp run], whatever
> that is?  It sounds like something in that machinery conflicts with
> how Lisp threads are implemented.

Note that this is a minimized reproducer.  I first noticed the issue
after I upgraded the GNU ELPA package debbugs, which recently got
support for threads using `make-thread'.

In that package, the function `debbugs-gnu-show-reports' in
debbugs-gnu.el is called in a thread, and the backtrace is the same.
See debbugs-gnu.el:897.

I don't see `sleep-for' called directly there, but I didn't yet
investigate it very closely.  Maybe Michael (in Cc) knows more.

Previous Next

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