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

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Stefan Kangas <stefankangas@gmail.com>,  Alan Third <alan@idiocy.org>,
>>>   75275@debbugs.gnu.org
>>> Date: Thu, 02 Jan 2025 08:30:25 +0100
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > 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]
>>> 
>>> I think that's the problem, see my other reply to Stefan.
>>
>> So should we add a condition before calling [NSApp run] that we are in
>> the main thread?
>
> ATM, I don't understand how we land in that line in ns_select_1 if not
> [NSThread isMainThread]. Maybe I need new glasses. I asked Stefan if he
> can see something in LLDB.

It must something in here:

  if (![NSThread isMainThread]
      || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
    thread_select (pselect, nfds, readfds, writefds,
		   exceptfds, timeout, sigmask);

Should we return here?

  else
    {
      struct timespec t = {0, 0};
      thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
    }

  /* FIXME: This draining of outerpool causes a crash when a buffer
     running over tramp is displayed and the user tries to use the
     menus.  I believe some other autorelease pool's lifetime
     straddles this call causing a violation of autorelease pool
     nesting.  There's no good reason to keep these here since the
     pool will be drained some other time anyway, but removing them
     leaves the menus sometimes not opening until the user moves their
     mouse pointer, but that's better than a crash.

     There must be something about running external processes like
     tramp that interferes with the modal menu code.

     See bugs 24472, 37557, 37922.  */

  // [outerpool release];
  // outerpool = [[NSAutoreleasePool alloc] init];

What is the following about? What is select_mutex or, for example?

  send_appdefined = YES;
  if (nr > 0)
    {
      pthread_mutex_lock (&select_mutex);
      select_nfds = nfds;
      select_valid = 0;
      if (readfds)
        {
          select_readfds = *readfds;
          select_valid += SELECT_HAVE_READ;
        }
      if (writefds)
        {
          select_writefds = *writefds;
          select_valid += SELECT_HAVE_WRITE;
        }

      if (timeout)
        {
          select_timeout = *timeout;
          select_valid += SELECT_HAVE_TMO;
        }

      pthread_mutex_unlock (&select_mutex);

      /* Inform fd_handler that select should be called.  */
      c = 'g';
      emacs_write_sig (selfds[1], &c, 1);
    }
  else if (nr == 0 && timeout)
    {
      /* No file descriptor, just a timeout, no need to wake fd_handler.  */
      double time = timespectod (*timeout);
      timed_entry = [[NSTimer scheduledTimerWithTimeInterval: time
                                                      target: NSApp
                                                    selector:
                                  @selector (timeout_handler:)
                                                    userInfo: 0
                                                     repeats: NO]
                      retain];
    }
  else /* No timeout and no file descriptors, can this happen?  */
    {
      /* Send appdefined so we exit from the loop.  */
      ns_send_appdefined (-1);
    }

  block_input ();
  ns_init_events (&event);

  [NSApp run];