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

Previous Next

Full log

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25172 <at> debbugs.gnu.org, Elias Mårtenson <lokedhs <at> gmail.com>,
 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 19:25:19 +0100

On Dez 13 2016, Eli Zaretskii <eliz <at> gnu.org> wrote:

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

Installing debuginfo for glibc and/or `thread apply all bt' will most
likely give more information.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Previous Next

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