From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2 Date: Thu, 02 Jan 2025 09:13:50 +0200 Message-ID: <86bjwplmc1.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9889"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75275@debbugs.gnu.org To: Stefan Kangas , Alan Third , Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 08:14:14 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tTFPJ-0002Ty-Vw for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 08:14:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTFPB-0006GZ-3f; Thu, 02 Jan 2025 02:14:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTFP9-0006Fh-3I for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 02:14:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tTFP8-0002Jt-MC for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 02:14:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=eyoZC/SV3cbjQAnNSniKPBQt8e6d4MB2KvXKbKrnbzk=; b=Hzr5hwQLSHuaQPY5y1EIa0YTyxaUDY5oUzXSQnav9vXlsmVwdiFmNHdSYmwgrkqnwHDI7WHFoklc3eyFb2MiLmP/vcpvJ5sDaYW7iqcX0filkfPMe+dRsZbE4om2nRSiMhcn8pl6ZMGvIXNMHm/+gyjmcVsYIj5/Jv2fqpKsOut51z9AfTpEkunNBIUozvwJwukPXvpEB3mLskptL9tvj7Dcq3MomxoPlZofsqeAQZC2aojNNv2sLAmbkI1Jg6dn9e0tkstEj0M/vGPOTnu8L9gQT+DDEIUabXa16m3Cpg+eQmHF4TnVQAQkDWWaCiu9jYtNPceKo9+hirBapPm1DA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTFP8-0000dr-EV for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 02:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 07:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75275 X-GNU-PR-Package: emacs Original-Received: via spool by 75275-submit@debbugs.gnu.org id=B75275.17358020412454 (code B ref 75275); Thu, 02 Jan 2025 07:14:02 +0000 Original-Received: (at 75275) by debbugs.gnu.org; 2 Jan 2025 07:14:01 +0000 Original-Received: from localhost ([127.0.0.1]:42539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTFP7-0000dV-2x for submit@debbugs.gnu.org; Thu, 02 Jan 2025 02:14:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50964) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTFP5-0000dG-4x for 75275@debbugs.gnu.org; Thu, 02 Jan 2025 02:14:00 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTFOy-0002J4-E6; Thu, 02 Jan 2025 02:13:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=eyoZC/SV3cbjQAnNSniKPBQt8e6d4MB2KvXKbKrnbzk=; b=SJBAJcXnpP7F1+pAfge5 FUCg0NfZRgV+LZifOgP9P5pFdR7kCvMC7x8h2jK90qCuG2GIHVJrdH4Akw1CEv4/qsRq8Jgs1x3eK M1Q7B4NxQNeQt4Rv6nZYDUHSpyKFfMKYlFYVdx/geFqN3KTQK8dJ56bfBEQebJau/D9Nhg34TnNEM Ln/pdjbpdb6XUll2hCt7n1+8n/FRvaoPbiq67gA9ZoIGSArc7yj0jEmj9cf2PGOIRXSX/v7V8N23R BGSfKTpv6CiK6ITYnwbIQopTqweR/bvi9q2DkKay5Xd/vyc7XFeqaJ2U7tdY5bEBZnBydbu2xrtFR xxdnLFSebnmKzA==; In-Reply-To: (message from Stefan Kangas on Wed, 1 Jan 2025 22:57:38 -0600) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298136 Archived-At: > From: Stefan Kangas > Date: Wed, 1 Jan 2025 22:57:38 -0600 > > 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. 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. > When I kill the process in the lldb window with Ctrl+C, I can get the > following (this is on emacs-30): > > [...] > 2025-01-02 05:47:20.778199+0100 emacs[78593:1366649] [General] > nextEventMatchingMask should only be called from the Main Thread! > Process 78593 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP > frame #0: 0x000000018e12dbbc libsystem_kernel.dylib`__psynch_mutexwait + 8 > libsystem_kernel.dylib`: > -> 0x18e12dbbc <+8>: b.lo 0x18e12dbdc ; <+40> > 0x18e12dbc0 <+12>: pacibsp > 0x18e12dbc4 <+16>: stp x29, x30, [sp, #-0x10]! > 0x18e12dbc8 <+20>: mov x29, sp > Target 0: (emacs) stopped. > (lldb) bt all > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP > * frame #0: 0x000000018e12dbbc libsystem_kernel.dylib`__psynch_mutexwait + 8 > frame #1: 0x000000018e1693f8 > libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_wait + 84 > frame #2: 0x000000018e166dbc > libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_slow + 220 > frame #3: 0x00000001003bfb94 > emacs`sys_mutex_lock(mutex=0x0000000100b7bd30) at systhread.c:140:15 > frame #4: 0x00000001003bcef8 > emacs`acquire_global_lock(self=0x0000000100b074d0) at thread.c:160:3 > frame #5: 0x00000001003bdce0 This is the main thread waiting for the global lock, which is expected. > 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? 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. >From the backtrace of the new Lisp thread, it looks like it finished sleeping for 1 sec and then it proceeds to calling [NSApp run] -- is this correct behavior for a non-main thread? E.g., does that try to run the main thread (which is parked inside sys_mutex_lock, waiting for the global lock to become free)?