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

From: Paul Eggert <[email-masked]>
Date: Wed, 27 Aug 2025 08:31:18 -0700

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.

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

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.