[Bug gdb/17511] Program received signal SIGTRAP, after step to signal handler -> step inside handler -> continue

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  abbdbd03db7eea82cadbb418da733991cba91b15 (commit)
      from  5a4b0ccc20ba30caef53b01bee2c0aaa5b855339 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=abbdbd03db7eea82cadbb418da733991cba91b15

commit abbdbd03db7eea82cadbb418da733991cba91b15
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Oct 28 15:51:30 2014 +0000

    Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal
handler

    I noticed that when I single-step into a signal handler with a
    pending/queued signal, the following single-steps while the program is
    in the signal handler leave $eflags.TF set.  That means subsequent
    continues will trap after one instruction, resulting in a spurious
    SIGTRAP being reported to the user.

    This is a kernel bug; I've reported it to kernel devs (turned out to
    be a known bug).  I'm seeing it on x86_64 Fedora 20 (Linux
    3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream.

    This commit extends gdb.base/sigstep.exp to cover this use case,
    xfailed.

    Here's what the bug looks like:

     (gdb) start
     Temporary breakpoint 1, main () at si-handler.c:48
     48        setup ();
     (gdb) next
     50        global = 0; /* set break here */

    Let's queue a signal, so we can step into the handler:

     (gdb) handle SIGUSR1
     Signal        Stop      Print   Pass to program Description
     SIGUSR1       Yes       Yes     Yes             User defined signal 1
     (gdb) queue-signal SIGUSR1

    TF is not set:

     (gdb) display $eflags
     1: $eflags = [ PF ZF IF ]

    Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1:

     (gdb) si
     sigusr1_handler (sig=0) at si-handler.c:31
     31      {
     1: $eflags = [ PF ZF IF ]

    No TF yet.  But another single-step...

     (gdb) si
     0x0000000000400621      31      {
     1: $eflags = [ PF ZF TF IF ]

    ... ends up with TF left set.  This results in PTRACE_CONTINUE
    trapping after each instruction is executed:

     (gdb) c
     Continuing.

     Program received signal SIGTRAP, Trace/breakpoint trap.
     0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31
     31      {
     1: $eflags = [ PF ZF TF IF ]

     (gdb) c
     Continuing.

     Program received signal SIGTRAP, Trace/breakpoint trap.
     sigusr1_handler (sig=10) at si-handler.c:32
     32        global = 0;
     1: $eflags = [ PF ZF TF IF ]
     (gdb)

    Note that even another PTRACE_SINGLESTEP does not fix it:

     (gdb) si
     33      }
     1: $eflags = [ PF ZF TF IF ]
     (gdb)

    Eventually, it gets "fixed" by the rt_sigreturn syscall, when
    returning out of the handler:

     (gdb) bt
     #0  sigusr1_handler (sig=10) at si-handler.c:33
     #1  <signal handler called>
     #2  main () at si-handler.c:50
     (gdb) set disassemble-next-line on
     (gdb) si
     0x0000000000400632      33      }
        0x0000000000400631 <sigusr1_handler+17>:     5d      pop    %rbp
     => 0x0000000000400632 <sigusr1_handler+18>:     c3      retq
     1: $eflags = [ PF ZF TF IF ]
     (gdb)
     <signal handler called>
     => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00    mov   
$0xf,%rax
     1: $eflags = [ PF ZF TF IF ]
     (gdb) si
     <signal handler called>
     => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05   syscall
     1: $eflags = [ PF ZF TF IF ]
     (gdb)
     main () at si-handler.c:50
     50        global = 0; /* set break here */
     => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00   movl  
$0x0,0x2009cb(%rip)        # 0x601040 <global>
     1: $eflags = [ PF ZF IF ]
     (gdb)

    The bug doesn't happen if we instead PTRACE_CONTINUE into the signal
    handler -- e.g., set a breakpoint in the handler, queue a signal, and
    "continue".

    gdb/testsuite/
    2014-10-28  Pedro Alves  <palves@redhat.com>

        PR gdb/17511
        * gdb.base/sigstep.c (handler): Add a few more writes to 'done'.
        * gdb.base/sigstep.exp (other_handler_location): New global.
        (advance): Support stepping into the signal handler, and running
        commands while in the handler.
        (in_handler_map): New global.
        (top level): In the advance test, add combinations for getting
        into the handler with stepping commands, and for running commands
        in the handler.  Add comment descripting the advancei tests.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/ChangeLog            |   12 +++++
 gdb/testsuite/gdb.base/sigstep.c   |    5 ++
 gdb/testsuite/gdb.base/sigstep.exp |   93 +++++++++++++++++++++++++++++++-----
 3 files changed, 97 insertions(+), 13 deletions(-)

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