Crash or hang if SIGSEGV+SIGALRM are nested

[Takashi Yano]

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

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