bug#25172: 26.0.50; Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)

[Eli Zaretskii <eliz@gnu.org>]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Tue, 13 Dec 2016 12:14:44 +0800
> Cc: Clément Pit--Claudel <clement.pit@gmail.com>, 
> 	25172@debbugs.gnu.org
> 
> This is the gdb output for the SIGSEV case. Note that there is a summary of all the threads first, and then the
> "bt full" output:

There's something here I don't understand.  It looks like 9 threads
are stuck in acquire_global_lock, which is fine.  The main thread was
executing some timer (probably, the one set up by global-eldoc-mode),
when it was delivered SIGSEGV.  There's one more thread running this:

  Stack trace of thread 23775: 
  #0 0x00007f5687e5e426 __sigsuspend (libc.so.6) 
  #1 0x0000000000578385 deliver_thread_signal (emacs-26.0.50) 
  #2 0x00000000005783f8 deliver_fatal_thread_signal (emacs-26.0.50) 
  #3 0x00000000005785ae handle_sigsegv (emacs-26.0.50) 
  #4 0x00007f5688810080 n/a (libpthread.so.0) 

This seems to be some thread, which was hit by SIGSEGV, and since it
is not the main thread, it calls pdthread_kill to kill the main
thread, which explains why the main thread received the signal.  But
what I don't understand is what was this thread 23775 doing before it
hit SIGSEGV?  The backtrace stops at handle_sigsegv, without revealing
that.

(There are three more threads calling 'poll', probably started by
Glib/GTK.)

Bottom line, I'm unsure what could be the reason for this one.