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

Previous Next

Full log

Message #47 received at 25172 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elias Mårtenson <lokedhs <at> gmail.com>
Cc: 25172 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#25172: 26.0.50; Concurrency feature, sit-for doesn't work
 (crashing and unexpected behaviour)
Date: Tue, 13 Dec 2016 18:23:46 +0200

> From: Elias Mårtenson <lokedhs <at> gmail.com>
> Date: Tue, 13 Dec 2016 12:14:44 +0800
> Cc: Clément Pit--Claudel <clement.pit <at> gmail.com>, 
> 	25172 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.