[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: 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 <address@hidden>
> Date: Tue, 13 Dec 2016 12:14:44 +0800
> Cc: Clément Pit--Claudel <address@hidden>, 
>       address@hidden
> 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

(There are three more threads calling 'poll', probably started by

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]