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.y...@nifty.ne.jp> -- 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
