bug#30364: 26.0.91; thread crash on macos

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 17 Feb 2018 10:40:10 -0800
> Cc: Noam Postavsky <npostavs@gmail.com>, 30364@debbugs.gnu.org, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>
> 
> On Sat, Feb 17, 2018 at 10:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > When this crashes, is one of the threads you launched always doing GC,
> > like in the first backtrace you've shown?
> 
> I can tell this by the mark_object/mark_vectorlike calls in the stack,
> right?

Yes.

> Ultimately, I was trying to port company-dabbrev to use threads. I
> noticed the crash while working on it, so the 100 threads at the same
> time was just a way of more consistently reproducing it. I could
> probably have run the 100 threads serially to reproduce it, I don't
> know.

They do run serially, the way you wrote the code.  The call to
make-thread creates the thread, but the thread doesn't run, it waits
for the currently-running thread to release the global lock.
Normally, I'd expect the first of the 100 threads to start running
almost immediately, because you don't do anything in the main thread.
But the other 99 will wait.  Whether some of them will start running
before the first one exits, depends on the code of the thread
function, and you didn't show all of it: I understand that the bulk is
in company-mode.

> I don't know what this is, but I do know that there are
> (input-pending-p)'s in the thread from the current implementation.

Where are they?  I don't see those input-pending-p calls in the code
on the page to which you referred. 

> They don't need to be there (i guess they'd be replaced by
> thread-yields, but when I did that it got very slow). I don't have
> time to test if removing those fixes the crashes just yet, but could
> that be causing the crash? The thread also calls `message`, I don't
> know if that's considered "UI stuff"

If we are to believe to the backtrace, the thread that crashed was the
main thread, and it crashed inside pthread_mutex_lock.  Which probably
means some snafu with pthreads synchronization functions.  But the NS
port has some complicated architecture wrt threads, so maybe that's
why it crashes.