GNU bug report logs - #37892
27.0.50; Crash when signaling a thread

Previous Next

Package: emacs;

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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37892 in the body.
You can then email your comments to 37892 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Wed, 23 Oct 2019 17:08:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michał Krzywkowski <mkrzywkow <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 23 Oct 2019 17:08:02 GMT) Full text and rfc822 format available.

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

From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Crash when signaling a thread
Date: Wed, 23 Oct 2019 19:06:42 +0200
[Message part 1 (text/plain, inline)]
Repository revision: b7037662e1111d55218fb2345f9ebb9ed3ebef13

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
  #6  0x00000000005c5e62 in really_call_select (arg=0x7fffee0253b0) at thread.c:596
  #7  0x00000000005c68c7 in thread_select
      (func=<optimized out>, max_fds=max_fds <at> entry=13, rfds=rfds <at> entry=0x7fffee025460, wfds=<optimized out>, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7fffee025a50, sigmask=0x0) at thread.c:616
  #8  0x00000000005e3058 in xg_select (fds_lim=13, rfds=rfds <at> entry=0x7fffee025b80, wfds=wfds <at> entry=0x7fffee025c00, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7fffee025a50, sigmask=sigmask <at> entry=0x0)
      at xgselect.c:73
  #9  0x00000000005a6fae in wait_reading_process_output
      (time_limit=<optimized out>, nsecs=<optimized out>, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=XIL(0), wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
      at process.c:5519
  #10 0x0000000000503119 in kbd_buffer_get_event (end_time=0x7fffee026360, used_mouse_menu=0x0, kbp=<synthetic pointer>) at lisp.h:1032
  #11 0x0000000000503119 in read_event_from_main_queue (used_mouse_menu=0x0, local_getcjmp=0x7fffee026090, end_time=0x7fffee026360) at keyboard.c:2152
  #12 0x0000000000503119 in read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>, prev_event=<optimized out>, local_getcjmp=<optimized out>, end_time=<optimized out>) at keyboard.c:2216
  #13 0x0000000000503119 in read_char (commandflag=commandflag <at> entry=0, map=map <at> entry=XIL(0), prev_event=prev_event <at> entry=XIL(0), used_mouse_menu=used_mouse_menu <at> entry=0x0, end_time=0x7fffee026360)
      at keyboard.c:2826
  #14 0x000000000058a51e in read_filtered_event (no_switch_frame=false, ascii_required=false, error_nonascii=false, input_method=<optimized out>, seconds=XIL(0xa8a86f)) at lisp.h:1032
  #15 0x000000000056a7e3 in Ffuncall (nargs=4, args=args <at> entry=0x7fffee026430) at lisp.h:2109
  #16 0x000000000059d2b1 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
  #17 0x000000000056c250 in apply_lambda (fun=XIL(0x7ffff031e795), args=<optimized out>, count=count <at> entry=1) at eval.c:2926
  #18 0x000000000056c52b in eval_sub (form=<optimized out>) at eval.c:2348
  #19 0x000000000056cbed in Fprogn (body=XIL(0)) at eval.c:462
  #20 0x000000000056cbed in funcall_lambda (fun=XIL(0x12a7d23), nargs=0, arg_vector=0x1465e78) at eval.c:3060
  #21 0x000000000056a73f in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x1465e70) at eval.c:2808
  #22 0x00000000005c61d8 in invoke_thread_function () at thread.c:702
  #23 0x0000000000569b12 in internal_condition_case (bfun=bfun <at> entry=0x5c61a0 <invoke_thread_function>, handlers=handlers <at> entry=XIL(0x30), hfun=hfun <at> entry=0x5c5bd0 <record_thread_error>) at eval.c:1355
  #24 0x00000000005c60c2 in run_thread (state=0x1465e50) at lisp.h:1032
  #25 0x00007ffff48e1fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
  #26 0x00007ffff47254cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Full backtrace in attachment.

[gdb.txt (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
-- 
Michał Krzywkowski
PGP: A5A7 06C4 28EF 8F64 2868 13A1 7BDE C129 F0B8 09A1

[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Fri, 25 Oct 2019 08:45:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michał Krzywkowski <mkrzywkow <at> gmail.com>
Cc: 37892 <at> debbugs.gnu.org
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Fri, 25 Oct 2019 11:44:16 +0300
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sat, 26 Oct 2019 12:31:01 GMT) Full text and rfc822 format available.

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

From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37892 <at> debbugs.gnu.org,
 Michał Krzywkowski <mkrzywkow <at> gmail.com>
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sat, 26 Oct 2019 14:29:43 +0200
[Message part 1 (text/plain, inline)]
>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:
    >> 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

    Eli> Emacs doesn't allow signals while it waits for input.

    Eli> We could ignore thread-signal in such cases, or we could make it an
    Eli> error (which will then signal an error in the thread which called
    Eli> thread-signal).  What do people think?  Are there any other ideas for
    Eli> handling this situation?

Maybe the signal should be raised in the thread right after it returns
from sit-for?  Ignoring signals sounds like a bad idea.

    Eli> Michał, can you tell why you needed to call thread-signal while the
    Eli> thread was in sit-for?

I wanted to signal some background thread which was doing some work and
then Emacs crashed, because it just so happened that it was in sit-for.
The thread function was doing _more_ than just sit-for.

I actually don't care (and can't know) what another thread is doing, I
just want to send a signal to it.

    Eli> Thanks.

Thank you.


--
Michał Krzywkowski
PGP: A5A7 06C4 28EF 8F64 2868 13A1 7BDE C129 F0B8 09A1
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sat, 26 Oct 2019 13:00:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michał Krzywkowski <mkrzywkow <at> gmail.com>
Cc: 37892 <at> debbugs.gnu.org
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sat, 26 Oct 2019 15:58:58 +0300
> From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
> Cc: Michał Krzywkowski <mkrzywkow <at> gmail.com>,
>  37892 <at> debbugs.gnu.org
> Date: Sat, 26 Oct 2019 14:29:43 +0200
> 
>     Eli> Emacs doesn't allow signals while it waits for input.
> 
>     Eli> We could ignore thread-signal in such cases, or we could make it an
>     Eli> error (which will then signal an error in the thread which called
>     Eli> thread-signal).  What do people think?  Are there any other ideas for
>     Eli> handling this situation?
> 
> Maybe the signal should be raised in the thread right after it returns
> from sit-for?

We don't have any mechanism for doing that.

> Ignoring signals sounds like a bad idea.

It is better than crashing.  It is also not much worse than
interrupting the thread at some arbitrary random point.

>     Eli> Michał, can you tell why you needed to call thread-signal while the
>     Eli> thread was in sit-for?
> 
> I wanted to signal some background thread which was doing some work and
> then Emacs crashed, because it just so happened that it was in sit-for.
> The thread function was doing _more_ than just sit-for.
> 
> I actually don't care (and can't know) what another thread is doing, I
> just want to send a signal to it.

But thread-signal is not for causing an error in a thread, it is for
unblocking a thread that waits on a mutex or a condvar.  So why would
you use it when the thread is not blocked?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sun, 27 Oct 2019 10:17:02 GMT) Full text and rfc822 format available.

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

From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37892 <at> debbugs.gnu.org,
 Michał Krzywkowski <mkrzywkow <at> gmail.com>
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sun, 27 Oct 2019 11:16:03 +0100
[Message part 1 (text/plain, inline)]
>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:
    Eli> Michał, can you tell why you needed to call thread-signal while the
    Eli> thread was in sit-for?
    >>
    >> I wanted to signal some background thread which was doing some work and
    >> then Emacs crashed, because it just so happened that it was in sit-for.
    >> The thread function was doing _more_ than just sit-for.
    >>
    >> I actually don't care (and can't know) what another thread is doing, I
    >> just want to send a signal to it.

    Eli> But thread-signal is not for causing an error in a thread, it is for
    Eli> unblocking a thread that waits on a mutex or a condvar.  So why would
    Eli> you use it when the thread is not blocked?


Then I think documentation for that function should be changed to
explicitly say that the signal will *only* be delivered if the target
thread is in a "blocked call to ‘mutex-lock’, ‘condition-wait’, or
‘thread-join’".

Currently, the docstring of thread-signal just says that the function
will interrupt threads which are blocked, but does not actually say that
the signal will be delivered only in those cases.  In fact, it says that
it works like signal, so I don't think it's unreasonable to assume that
it will just interrupt a thread whatever it's doing.

--
Michał Krzywkowski
PGP: A5A7 06C4 28EF 8F64 2868 13A1 7BDE C129 F0B8 09A1
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sun, 27 Oct 2019 13:27:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michał Krzywkowski <mkrzywkow <at> gmail.com>
Cc: 37892 <at> debbugs.gnu.org
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sun, 27 Oct 2019 15:25:50 +0200
> From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
> Cc: Michał Krzywkowski <mkrzywkow <at> gmail.com>,
>  37892 <at> debbugs.gnu.org
> Date: Sun, 27 Oct 2019 11:16:03 +0100
> 
>     >> I actually don't care (and can't know) what another thread is doing, I
>     >> just want to send a signal to it.
> 
>     Eli> But thread-signal is not for causing an error in a thread, it is for
>     Eli> unblocking a thread that waits on a mutex or a condvar.  So why would
>     Eli> you use it when the thread is not blocked?
> 
> Then I think documentation for that function should be changed to
> explicitly say that the signal will *only* be delivered if the target
> thread is in a "blocked call to ‘mutex-lock’, ‘condition-wait’, or
> ‘thread-join’".
> 
> Currently, the docstring of thread-signal just says that the function
> will interrupt threads which are blocked, but does not actually say that
> the signal will be delivered only in those cases.  In fact, it says that
> it works like signal, so I don't think it's unreasonable to assume that
> it will just interrupt a thread whatever it's doing.

The function does work like a signal, but Emacs cannot be interrupted
while it waits for input.  In all other cases your signal will be
delivered, and if unhandled, it will terminate the thread.

If we decide that thread-signal will have no effect while a thread
waits for input, then we will document that, of course.  My question
was meant to understand your intent for signaling a thread at
arbitrary time, because the effect of that is unpredictable, even if
the crash didn't happen.  I wanted to understand your thinking and
rationale, so as to have a better basis for the decision of how to fix
this problem.

So could you please elaborate on your rationale?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sun, 27 Oct 2019 19:28:03 GMT) Full text and rfc822 format available.

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

From: Michał Krzywkowski <mkrzywkow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37892 <at> debbugs.gnu.org,
 Michał Krzywkowski <mkrzywkow <at> gmail.com>
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sun, 27 Oct 2019 20:26:43 +0100
[Message part 1 (text/plain, inline)]
>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:
    Eli> But thread-signal is not for causing an error in a thread, it is for
    Eli> unblocking a thread that waits on a mutex or a condvar.  So why would
    Eli> you use it when the thread is not blocked?
    >>
    >> Then I think documentation for that function should be changed to
    >> explicitly say that the signal will *only* be delivered if the target
    >> thread is in a "blocked call to ‘mutex-lock’, ‘condition-wait’, or
    >> ‘thread-join’".
    >>
    >> Currently, the docstring of thread-signal just says that the function
    >> will interrupt threads which are blocked, but does not actually say that
    >> the signal will be delivered only in those cases.  In fact, it says that
    >> it works like signal, so I don't think it's unreasonable to assume that
    >> it will just interrupt a thread whatever it's doing.

    Eli> The function does work like a signal, but Emacs cannot be interrupted
    Eli> while it waits for input.  In all other cases your signal will be
    Eli> delivered, and if unhandled, it will terminate the thread.

    Eli> If we decide that thread-signal will have no effect while a thread
    Eli> waits for input, then we will document that, of course.  My question
    Eli> was meant to understand your intent for signaling a thread at
    Eli> arbitrary time, because the effect of that is unpredictable, even if
    Eli> the crash didn't happen.  I wanted to understand your thinking and
    Eli> rationale, so as to have a better basis for the decision of how to fix
    Eli> this problem.

    Eli> So could you please elaborate on your rationale?

Actually there is no deeper reason behind it.  I was just testing
threads in Emacs, seeing how things behave.  I certainly would think
twice before writing code that interrupts a thread at an arbitrary point
in a real program.

When it comes to sit-for, I use it sometimes.  Is there a reason not to
use it in threads?

In any case, I'm not encouraging anyone to program like that, I'm just
reporting a crash...

--
Michał Krzywkowski
PGP: A5A7 06C4 28EF 8F64 2868 13A1 7BDE C129 F0B8 09A1
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37892; Package emacs. (Sun, 05 Dec 2021 03:16:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michał Krzywkowski <mkrzywkow <at> gmail.com>
Cc: 37892 <at> debbugs.gnu.org
Subject: Re: bug#37892: 27.0.50; Crash when signaling a thread
Date: Sun, 05 Dec 2021 04:15:07 +0100
Michał Krzywkowski <mkrzywkow <at> gmail.com> writes:

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

I can reproduce this in Emacs 27.1, but not in Emacs 28, so it seems
like this has been fixed, and I'm closing this bug report.  If the
problem is still present in Emacs 28, please respond to the debbugs
address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 37892 <at> debbugs.gnu.org and Michał Krzywkowski <mkrzywkow <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 05 Dec 2021 03:16:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 02 Jan 2022 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 76 days ago.

Previous Next


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