Takashi Yano via Cygwin wrote:
On Wed, 28 May 2025 21:57:07 +0900
Takashi Yano wrote:
Hi Christian,
On Mon, 19 May 2025 12:55:46 +0200
Christian Franke wrote:
The attached testcase was originally intended to investigate why a
SIGSEGV from non-signal code could interrupt an already running signal
handler.
https://sourceware.org/pipermail/cygwin-patches/2025q2/013703.html
If run without strace, the testcase may crash silently (with exit status 0):
$ uname -r
3.7.0-0.98.gb39b510c1ce6.x86_64
$ gcc -o sigsegvalrm sigsegvalrm.c
$ while { ./sigsegvalrm; s=$?; echo exit $s; test $s = 42; }; do :; done
...
[SEGV during ALRM]
[SEGV]
[ALRM during SEGV]
[ALRM]
101 total, 24 ALRM during SEGV, 13 SEGV during ALRM
exit 42
...
[SEGV during ALRM]
[ALRM]
[SEGV]
[ALRM]
[SEGV]
[ALRM during SEGV]
[SEGV]
[ALRM]
[SEGV]
exit 0
If the above was run with 'strace ./sigsegvalrm', the result was an
infinte loop:
https://cygwin.com/pipermail/cygwin/2025-May/258144.html
Fortunately this is fixed since b39b510c. A new result:
...
[SEGV during ALRM]
205 556472 [main] sigsegvalrm 1342 fhandler_console::write: 19 =
fhandler_console::write(...)
91 556563 [main] sigsegvalrm 1342 write: 19 = write(1, 0x100403020, 19)
81 556644 [main] sigsegvalrm 1342 clock_nanosleep: clock_nanosleep
(0.001000000)
8396 565040 [itimer] sigsegvalrm 1342 timer_tracker::thread_func:
0x7FFE4CC69640 timer expired
230 565270 [main] sigsegvalrm 1342 clock_nanosleep: 0 =
clock_nanosleep(1, 0, 0.001000000, 0.d)
123 565393 [itimer] sigsegvalrm 1342 timer_tracker::thread_func:
0x7FFE4CC69640 sending signal 14
230 565623 [main] sigsegvalrm 1342 set_signal_mask: setmask 2400,
newmask 0, mask_bits 2400
147 565770 [main] sigsegvalrm 1342 pthread_sigmask: 0 =
pthread_sigmask(0, 0x100407128, 0x0)
220 565990 [itimer] sigsegvalrm 1342 sig_send: sendsig 0x158, pid
1342, signal 14, its_me 1
278 566268 [main] sigsegvalrm 1342 pthread_sigmask: 0 =
pthread_sigmask(0, 0x0, 0x100407128)
--- Process 148 (pid: 1342), exception c0000005 at 0000000100401287
1579 567847 [sig] sigsegvalrm 1342 sigpacket::process: signal 14
processing
189 568036 [sig] sigsegvalrm 1342 init_cygheap::find_tls: sig 14
235 568271 [sig] sigsegvalrm 1342 sigpacket::process: using tls
0x7FFFFCE00
195 568466 [main] sigsegvalrm 1342 exception::handle: In
cygwin_except_handler exception 0xC0000005 at 0x100401287 sp 0x7FFFFCBE0
131 568597 [sig] sigsegvalrm 1342 sigpacket::process: signal 14,
signal handler 0x100401080
82 568679 [main] sigsegvalrm 1342 exception::handle: In
cygwin_except_handler signal 11 at 0x100401287
79 568758 [sig] sigsegvalrm 1342 sigpacket::setup_handler:
suspending thread, tls 0x7FFFFCE00, _main_tls 0x7FFFFCE00
[~30s delay]
--- Process 148 (pid: 1342) thread 14964 created
--- Process 148 (pid: 1342) thread 14048 created
[~30s delay]
--- Process 148 (pid: 1342) thread 5184 exited with status 0x0
--- Process 148 (pid: 1342) thread 5056 exited with status 0x0
[several minutes delay]
--- Process 148 (pid: 1342) thread 9388 created
The process then ignores SIGKILL.
Thanks for reporting this. I finally found the solution.
Please test
https://cygwin.com/pipermail/cygwin-patches/2025q2/013731.html
https://cygwin.com/pipermail/cygwin-patches/2025q2/013732.html
Updated to v2:
https://cygwin.com/pipermail/cygwin-patches/2025q2/013731.html
https://cygwin.com/pipermail/cygwin-patches/2025q2/013733.html
Problem does no longer occur if both patches are applied, thanks!
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.
--
Thanks,
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
