bug#75275: 30.0.92; `make-thread` bug on macOS 15.2

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Stefan Kangas <stefankangas@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.