GNU bug report logs -
#37892
27.0.50; Crash when signaling a thread
Previous Next
Reported by: Michał Krzywkowski <mkrzywkow <at> gmail.com>
Date: Wed, 23 Oct 2019 17:08:02 UTC
Severity: normal
Found in version 27.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 37892 <at> debbugs.gnu.org (full text, mbox):
> From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
> Date: Wed, 23 Oct 2019 19:06:42 +0200
>
> When I evaluate this sexp, Emacs aborts:
>
> (let ((thread (make-thread (lambda () (sit-for 1.0)))))
> (sit-for 0.5)
> (thread-signal thread 'error nil))
>
> Backtrace:
>
> Thread 5 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:371
> 371 signal (sig, SIG_DFL);
> #0 0x000000000041f40b in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:371
> #1 0x000000000041f866 in emacs_abort () at sysdep.c:2450
> #2 0x000000000042154b in signal_or_quit (error_symbol=XIL(0x90), data=XIL(0), keyboard_quit=<optimized out>) at eval.c:1598
> #3 0x0000000000421564 in Fsignal (error_symbol=<optimized out>, data=<optimized out>) at eval.c:1568
> #4 0x0000000000423929 in post_acquire_global_lock (self=<optimized out>) at thread.c:115
> #5 0x00000000005c5e62 in acquire_global_lock (self=0x1465e50) at thread.c:123
Emacs doesn't allow signals while it waits for input.
We could ignore thread-signal in such cases, or we could make it an
error (which will then signal an error in the thread which called
thread-signal). What do people think? Are there any other ideas for
handling this situation?
Michał, can you tell why you needed to call thread-signal while the
thread was in sit-for?
Thanks.
This bug report was last modified 3 years and 252 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.