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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75275 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 08:12:01 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

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

Then it's the other category of freezes I see with NS, and not
bug#72496. Which doesn't mean the cause might not be the same, in some
way.

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

I think it doesn't matter for this bug. The curious thing about 72496 is
that EmacsApp.run apparently handles events so that no beach ball
appears, but Emacs doesn't get a chance to handle its events. It's as if
the Cocoa event handling decouples itself from Emacs. And that's because
it doesn't return to ns_select_1. Anyway, different construction site
apparently.

I have something in my notes which might or might not help:

  * Breakpoint for errors displayed by macOS on stderr

  Set a breakpoint on CGPostError to find sources of errors.

  #+begin_src sh
  To find out from where macOS prints stuff to stderr, like
  023-07-20 13:41:17.073449+0200 emacs[53072:1205906] [default]
      CGSWindowShmemCreateWithPort failed on port 0
  b _os_log_error_impl
  b _os_log_impl
  b _os_log_debug_impl
  b _os_log_fault_impl
  #+end_src

If on of these breakpoints is hit when the error is displayed, we could
perhaps see why ns_select_1 calls EmacsApp.run. In my understanding, it
shouldn't because Cocoa event handling should only be done in the main
thread.

If the breakpoints are not hit, we could instrument ns_select_1 to call
an empty function do_break on which we could set a breakpoint.

  if (![NSThread isMainThread])
    do_break ();
  [NSApp run];

Or something like that. The question would be what in the code above the
[NSApp run] is wrong so that we land here. Probably some if condition.

CC to Alan Third.

Previous Next

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