The current segfault handler in -unittest mode is implemented as: https://github.com/dlang/druntime/blob/86e5cf3fa15afda116994da0c91f40aa7a5e6c6e/src/core/runtime.d#L571 However in the current implementation if there was a segfault then only one of the threads will emit its stack trace. If multiple threads are used then this may not be enough information - a random thread will be selected which may not be the thread which caused the segfault. It's also possible for external processes to send such a signal (for example `timeout -s SEGV 5m ./test` for timeouts with stack traces). It /is/ possible to force all threads to dump their stack trace. First this should be changed: https://github.com/dlang/druntime/blob/86e5cf3fa15afda116994da0c91f40aa7a5e6c6e/src/core/runtime.d#L586 And `SA_RESETHAND` removed (so we can reuse the signal handler). And then the thread which received the signal should dispatch the signal to all other threads (being careful those threads don't try to send the signal back). ---- I have a working prototype for MacOS, but not for Posix / Windows / other platforms yet.
SIGSEGV will only be delivered to the thread that caused the segfault. As per 'man 7 signal': > A signal may be process-directed or thread-directed. [...] A thread-directed signal is one that is targeted at a specific thread. A signal may be thread-directed because it was generated as a consequence of executing a specific machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE for a math error)
Readable version: > A signal may be process-directed or thread-directed. [...] > A thread-directed signal is one that is targeted at a specific thread. A signal may be > thread-directed because it was generated as a consequence of executing a specific > A machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for > an invalid memory access, or SIGFPE for a math error)
(In reply to FeepingCreature from comment #2) > Readable version: > > > A signal may be process-directed or thread-directed. [...] > > A thread-directed signal is one that is targeted at a specific thread. A signal may be > > thread-directed because it was generated as a consequence of executing a specific > > A machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for > > an invalid memory access, or SIGFPE for a math error) Thanks. This might have been just a problem on MacOS. I don't have a MacOS machine to test this on anymore, and I'm not sure whether this problem occurred on other OSes. > I have a working prototype for MacOS, but not for Posix / Windows / other platforms yet. This work has been lost, unfortunately.