public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "palves at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/17511] New: Program received signal SIGTRAP, after step to signal handler -> step inside handler -> continue
Date: Sun, 26 Oct 2014 22:15:00 -0000	[thread overview]
Message-ID: <bug-17511-4717@http.sourceware.org/bugzilla/> (raw)

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

            Bug ID: 17511
           Summary: Program received signal SIGTRAP, after step to signal
                    handler -> step inside handler -> continue
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

While writing a GDB test I noticed that when I have a signal pending/queued,
and I single-step into signal handler, and then issue another step inside the
handler, the following continues will result in spurious SIGTRAPS.

The problem is that $eflags.TF ends stuck/set.

I'm on Fedora 20 (Linux 3.16.4-200.fc20.x86_64).

Vis:

 (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) info inferiors
   Num  Description       Executable
 * 1    process 29953     si-handler
 (gdb) shell kill -SIGUSR1 29953
 (gdb) c
 Continuing.

 Program received signal SIGUSR1, User defined signal 1.
 main () at si-handler.c:50
 50        global = 0; /* set break here */
 (gdb) display $eflags
 1: $eflags = [ PF ZF IF ]

(With mainline GDB, you can instead just do "queue-signal SIGUSR1".)

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 ]

Looks fine so far.  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)

I don't get the bug if I instead PTRACE_CONTINUE into the signal
handler -- e.g., set a breakpoint in the handler, queue a signal,
and "continue".

Below's the code I was using to test this.

~~~~
/* This testcase is part of GDB, the GNU debugger.

   Copyright 2014 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */

#include <signal.h>

volatile int global;

static void
signal_handler (int sig)
{
  global = 0;
  global = 0;
  global = 0;
  global = 0;
  global = 0;
}

void
setup (void)
{
  /* Set up the signal handler.  */
  signal (SIGUSR1, signal_handler);
}

void
begin (void)
{
}

void
end (void)
{
}

int
main (void)
{
  setup ();
  begin ();
  end ();
  return 0;
}
~~~~

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


             reply	other threads:[~2014-10-26 22:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-26 22:15 palves at redhat dot com [this message]
2014-10-26 22:18 ` [Bug gdb/17511] " palves at redhat dot com
2014-10-28 15:52 ` cvs-commit at gcc dot gnu.org
2014-11-07 15:40 ` cvs-commit at gcc dot gnu.org
2014-12-25  0:46 ` cvs-commit at gcc dot gnu.org
2015-02-28 16:05 ` palves at redhat dot com
2015-03-01  5:22 ` palves at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-17511-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).