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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 75275 <at> debbugs.gnu.org
Subject: Re: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 09:53:01 +0200

> 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.

Previous Next

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