Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault

From: Eli Zaretskii <[email-masked]>
Date: Wed, 27 Aug 2025 19:44:59 +0300

> Date: Wed, 27 Aug 2025 08:31:18 -0700
> Cc: [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> On 2025-08-27 05:29, Eli Zaretskii wrote:
> > Paul, when a fatal signal is delivered to Emacs from outside, it goes
> > to the main thread, but what happens with other threads? do they keep
> > running as before, or do they stop?
> 
> Those fatal signals go to the main thread because if the OS delivers 
> them elsewhere, Emacs uses pthread_kill to redeliver them to the main 
> thread. In this situation the thread that originally got the signal is 
> suspended. All other threads keep running.
> 
> I suppose it's possible that the thread that originally got the signal 
> is not the main thread, and owns the global lock. If this is the case, 
> then either the shutdown code should not need to acquire the global 
> lock, or the thread that originally got the signal should release the 
> global lock in a safe way. As I recall, when this signal stuff was 
> written there was no global lock, so perhaps when the global lock was 
> added the possibility that I describe was not considered.

Yes, I think we should do something like that in
deliver_thread_signal.

> > And what about "synchronous" signals like SIGSEGV -- if a non-main
> > thread triggers such a signal, does the handler run in that thread, or
> > does it run in the main thread?
> 
> It depends on the signal. A SIGSEGV is considered to be fatal if garbage 
> collection is in progress, if it is triggered in a non-main thread, or 
> if Emacs thinks that it was not caused by stack overflow. A non-fatal 
> SIGSEGV causes Emacs to longjmp back to the top level command loop; 
> other threads keep running. A fatal SIGSEGV is handled as described above.

OK, thanks.

> The full story is a more complicated on Android and on MS-Windows. It's 
> not clear from the bug report which platform we're talking about, but I 
> suspect it's not MS-Windows (where you're the expert and wouldn't need 
> to ask me) or Android.

No, it wasn't on Windows, indeed.