Crash or hang if SIGSEGV+SIGALRM are nested

[Takashi Yano]

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

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>