Created attachment 13666 [details] patch making fail reproducible I ran into the following failure on x86_64-linux with target board unix/-m32/-fno-PIE/-no-pie and openSUSE Tumbleweed: ... (gdb) PASS: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: switch to sigtrap thread signal SIGTRAP^M Continuing with signal SIGTRAP.^M [Thread 0xf7da2ac0 (LWP 1690) exited]^M ^M Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M 0xf7fcc159 in __kernel_vsyscall ()^M (gdb) FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: signal SIGTRAP reaches handler ... I had difficulty reproducing at first, but after playing with it for a while, I realized that what I'm looking at are the effects of doing "signal SIGTRAP" to a thread that is somewhere inside or inbetween pthread_create and pthread_join, and the FAIL happens when stopped at a point where the signal is blocked. I modified the test-case to make the FAIL reproducible, and managed to reproduce it using native x86_64 on openSUSE Leap 15.2 (so, different kernel, libc, pointer size).
Created attachment 13667 [details] gdb.log
So, what I understand that happens is: - gdb command "signal SIGTRAP" sends the signal to the main thread using PTRACE_CONT - the signal is blocked, so it becomes pending - when the signal is unblocked, the pending signal is delivered, but because the inferior is ptraced, gdb is notified, and gdb does the stop/print/pass processing. This seems to contradict the documentation, which states: ... Invoking the signal command is not the same as invoking the kill utility from the shell. Sending a signal with kill causes GDB to decide what to do with the signal depending on the signal handling tables (see Signals). The signal command passes the signal directly to your program. ... I'm not sure whether the documentation needs to be updated, or gdb needs to be fixed (and indeed, can be fixed).
Duplicate. *** This bug has been marked as a duplicate of bug 26867 ***