[Converted from Gnats 2320]
I'm having problems getting GDB to not pass SIGINT to my program. In my main thread I do a sigwait for SIGINT. When I'm debugging, while gdb is running I may want to break gdb to set breakpoints or so, then I hit Ctrl-C (send SIGINT) but gdb does not break, instead SIGINT is passed to my program that gracefully terminates and gdb prints "Program exited normally". Of course "info handle" shows that SIGINT should not be being passed to my program:
(gdb) info handle SIGINT
Signal Stop Print Pass to program Description
SIGINT Yes Yes No Interrupt
GDB does not even print SIGINT signal delivery when I think it should.
GNU gdb 6.5
GNU/Linux 18.104.22.168 #3 PREEMPT i686
gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-3mdk)
Compile attached "test_gdb.cpp" file and run it under gdb. While running hit Ctrl+C to interrupt GDB. Program will terminate so no chance to debug it any more.
From: Daniel Jacobowitz <email@example.com>
Subject: Re: threads/2320: When using "sigwait" GDB doesn't trap SIGINT.
Ctrl+C terminates program when should break gdb.
Date: Sat, 29 Sep 2007 16:32:44 -0400
On Thu, Sep 20, 2007 at 08:53:13AM -0000, firstname.lastname@example.org wrote:
> I'm having problems getting GDB to not pass SIGINT to my program. In
> my main thread I do a sigwait for SIGINT. When I'm debugging, while
> gdb is running I may want to break gdb to set breakpoints or so,
> then I hit Ctrl-C (send SIGINT) but gdb does not break, instead
> SIGINT is passed to my program that gracefully terminates and gdb
> prints "Program exited normally".
Thanks for the clear report and test case. I discussed this with
Roland McGrath in the bugzilla.kernel.org entry you linked to; our
conclusion was that the kernel is correct to not report the SIGINT
in this case. Of course that's not the useful behavior for GDB.
I'm not planning to work on this right now, but here's some notes
on a possible solution if anyone else wants to.
- Define a new PTRACE_SETOPTIONS bit to enable the extra reporting.
- Report the signal as a special event, using a new PTRACE_EVENT_FOO
code in the high half-word of the wait status.
- Adjust GDB to set the new options bit when it sets other options.
Is this bug likely to be revisited or resolved in the short-term? Is it really
ASSIGNED to someone.
No, it is not really assigned. That seems to be some sort of bug in
our bugzilla installation. AFAIK nobody is actively working on this.
*** Bug 9468 has been marked as a duplicate of this bug. ***
See also bug #15250. However it seems options may be limited
if gdb and the inferior are sharing a terminal.