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?

What is your GDB version and OS? Can you produce a minimal C program where it also happens? — Ciro Santilli OurBigBook.com, Oct 28 '15 at 16:31
@CiroSantilli六四事件法轮功纳米比亚威视: This problem was solved four years ago (see below) - a sample program probably isn't that relevant anymore! — Malvineous, Oct 29 '15 at 05:22
1000+ people come here every year looking for answers :-) New questions can be closed as duplicates of this one. But I don't blame you if you forgot the details. — Ciro Santilli OurBigBook.com, Oct 29 '15 at 05:43

score 35 · Accepted Answer · edited May 23 '17 at 11:54

35

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.

edited May 23 '17 at 11:54

Community

1
1

answered Jun 22 '11 at 15:13

Jared Robinson

366
3
4

Unfortunately I wasn't able to unblock gdb like that when the underlying process hangs. Both gdb and my process still hang :-( Any other hints? – lethalman Jan 17 '14 at 14:18
1

for others wondering '' refers to the inferior process here (not gdb) – ricab Jan 30 '19 at 16:14

score 10 · Answer 2 · answered Aug 02 '14 at 08:01

10

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

answered Aug 02 '14 at 08:01

sunil

491
4
10

This doesn't work if the debugged process is invoking [`sigwait()`](https://manpath.be/c7/3/sigwait). And `handle SIGINIT stop` should be set, by default. – maxschlepzig Aug 24 '19 at 07:00
1

I have no reason to even doubt the wisdom of @maxschlepzig... and yet sunil's answer helped me to realize that `handle SIGINT pass` was the solution to the (~opposite) problem that Google brought me here with. – Martin Dorey Nov 27 '21 at 23:40

score 4 · Answer 3 · answered Jan 07 '17 at 01:36

4

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

answered Jan 07 '17 at 01:36

Yankes

1,958
19
20

I guess that causes the application to ignore the signal, but gdb still doesn't stop for me. – Carlo Wood May 10 '20 at 21:06

score 1 · Answer 4 · answered Oct 20 '18 at 05:25

1

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

answered Oct 20 '18 at 05:25

Resigned June 2023

4,638
3
38
49

If you are right, it is a bug. I cannot reproduce it - can you give an example or, better still, [file a bug report](https://github.com/hanslub42/rlwrap)? BTW: `gdb` uses `readline`, so why use `rlwrap` at all? – Hans Lub Oct 26 '18 at 14:55
@HansLub I was annoyed that GDB didn't remember my command history between sessions, hence my usage of `rlwrap`. I'm afraid I don't have the time to generate a bug report at present, sorry. – Resigned June 2023 Oct 26 '18 at 20:53

FairyFar · Answer 5 · 2022-02-15T10:44:21.697

1

I had a similar problem and I have solved it.

First, write a gdb script, the file name is sighhandler.gdb. The script file is in the project directory:

gdb_sigwait/src/sighandler.gdb

Then, source the above script file in the gdb initialization file (~/.gdbinit), for example:

source ~/gdb_sigwait/src/sighandler.gdb

The gdb script is too long. So, I created a github project to introduce and store the related code: https://github.com/fairyfar/gdb_sigwait

edited Feb 15 '22 at 10:44

answered Feb 14 '22 at 08:57

FairyFar

11
4

Hi FairyFar. Welcome to the stack! Please take the [tour](https://stackoverflow.com/tour) if you haven't already done so. – Captain Hat Feb 14 '22 at 11:14
Answers should be self-contained, and links should be for supplementing/clarifying content. Please update your answer so that the solution is included in the text. – Captain Hat Feb 14 '22 at 11:15
Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 15 '22 at 06:17

score 0 · Answer 6 · edited Dec 04 '13 at 03:20

0

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

gdb -tty = /dev/tty1

edited Dec 04 '13 at 03:20

jvperrin

3,368
1
23
33

answered Dec 04 '13 at 02:50

Sanjay

1

This doesn't fix the problem. The output does go to the other terminal, but when you press Ctrl+C on gdb's terminal, the program being debugged still catches the signal and exits cleanly, just as if you hadn't changed the tty at all. – Malvineous Jun 29 '14 at 01:30

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

6 Answers6

Linked