On Thu, 29 May 2025 17:32:19 +0200 Christian Franke wrote: > 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!
Thanks for testting! > 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(). -- 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
