GDB: Ctrl+C doesn't interrupt process as it usually does but rather terminates the program

Question

Normally when you run a program through GDB you can press Ctrl+C to interrupt it, e.g. if it gets stuck in an infinite loop and you want to get a backtrace.

I'm debugging a program (xmms2d as it happens) but in this program only, when I press Ctrl+C it gets treated as if GDB was not running - the program shuts down cleanly and then GDB tells me the program exited normally.

How do I get the usual GDB behaviour back, where Ctrl+C interrupts the program? Or is there another way to produce the same reaction in GDB as a Ctrl+C normally does?

Answer 1

I'll bet that xmms2d is using sigwait() to handle signals, which breaks gdb's ability to catch CTRL-C. See https://bugzilla.kernel.org/show_bug.cgi?id=9039

I got an idea for a workaround by reading Continue to debug after failed assertion on Linux? -- when I'm ready to break in gdb, I run "kill -TRAP <pid>" from another terminal window.

Answer 2

In the gdb prompt you can do "handle SIGINT stop" so that gdb catches CTRL-C

Answer 3

I had same problem caused by SDL signal handlers that interfere with gdb. One solution I find to workaround this when starting gdb:

start
call sigignore(2)
continue

Now all CTRL-C will be ignored by application.

If you attach to some process and want to restore it to original condition after debuging, you can do this:

set $oldcallback = signal(2, 0)
call sigignore(2)
continue

And when you are done:

call signal(2, $oldcallback)
detach

Answer 4

Note that running GDB under rlwrap breaks its ability to intercept ^C correctly. If you are doing this, then try running it without rlwrap.

Answer 5

You can change GDB's input/output target using the following command:

gdb -tty = /dev/tty1