bug#30364: 26.0.91; thread crash on macos

[Aaron Jensen]

On Sat, Feb 17, 2018 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.

Right, it is, in company-dabbrev.el

>> 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 are here: 
https://github.com/company-mode/company-mode/blob/master/company-dabbrev.el#L121

My goal was to remove them and add thread-yields to the loops.

That said, I just tested removing them and it still crashed.

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

Is there anything else I can do to provide more information?

Alan, are you able to reproduce it?

Thanks,

Aaron