[Bug threads/28347] New: FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: signal SIGTRAP reaches handler

[Bug threads/28347] New: FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: signal SIGTRAP reaches handler

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28347

            Bug ID: 28347
           Summary: FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread
                    1: signal SIGTRAP reaches handler
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Created attachment 13666
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13666&action=edit
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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/28347] FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: signal SIGTRAP reaches handler

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28347

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13667
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13667&action=edit
gdb.log

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/28347] FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 1: signal SIGTRAP reaches handler

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28347

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at sourceware dot org,
                   |                            |simark at simark dot ca

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.