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.
next 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: linkBe 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).