Takashi Yano via Cygwin wrote:
On Thu, 29 May 2025 17:32:19 +0200
Christian Franke wrote:
...
I still don't fully understand why a SIGSEGV triggered by an instruction
could interrupt a SIGALRM handler.
https://sourceware.org/pipermail/cygwin/2025-May/258145.html
I guess such behavior is valid from the POSIX point of view, but it is
at least unexpected. If the SIGALRM handler is already running, it
should have interrupted the thread such that the instruction triggering
the segfault is not executed until the SIGALRM handler returns.
I try to explain what is happing using the figure below.
<<<<<< Main thread >>>>>> < Signal Thread >
SIGNAL
main() handler1() handler2() QUEUE wait_sig()
| . . | |
| . . ALRM | |
+----------------------------------------->| ALRM |
| . . SEGV +--------->|
X----------------------------------------->| |
| . arm ALRM | |
+----------+ <----------------------------------------+
| . | SEGV |
| . +--------->|
| . | |
| . arm SEGV | |
+----------+ <-----------------------------+
. | | |
longjmp() | | |
+---------------------+ | |
| . . | |
| . . | |
The point is the exception handler does not arm SIGSEGV handler
directly. It just pushes the SIGSEGV into the signal queue.
The signal thread reads the queue and process it asynchronously,
and arms the handler().
I see. Thanks for nice explanation!
I created an issue at stress-ng upstream because at least the --mprotect
test is affected:
https://github.com/ColinIanKing/stress-ng/issues/529
--
Regards,
Christian
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
