When debugging a large C application, I see strange behavior from gdb: I can always abort a program by pressing Ctrl+C:
^C
Program received signal SIGINT, Interrupt.
0x76f58964 in select () at ../sysdeps/unix/syscall-template.S:81
81 in ../sysdeps/unix/syscall-template.S
(gdb)
However, after sufficient execution time (for example,> 1 day), I can no longer interrupt the program. When you try to interrupt the program with Ctrl+C, it gdbsimply shows
^C
Program received signal SIGINT, Interrupt.
and hangs there for several minutes to several hours. If this takes more than a few minutes, I usually open another terminal and kill gdbmanually to continue.
Question: Expected behavior from gdb? Can I set a parameter to avoid this?
Additional Information:
:
perf record -p $(pidof gdb) 10 , gdb . perf report :
90,82% gdb gdb [.] find_thread_ptid
9,13% gdb gdb [.] ptid_equal
0,02% gdb gdb [.] iterate_over_threads
0,01% gdb [kernel.kallsyms] [k] run_timer_softirq
0,01% gdb gdb [.] 0x0016a9a4
0,00% gdb gdb [.] 0x0015a480
0,00% gdb gdb [.] 0x0016a998
0,00% gdb gdb [.] is_exited
gdb, info threads, - ( ):
(gdb) info threads
Id Target Id Frame
3 Thread 0x764b8460 (LWP 10114) "socket listener" 0x76f60260 in accept () at ../sysdeps/unix/syscall-template.S:81
2 Thread 0x76cb8460 (LWP 10113) "loganalyzer" 0x76f58964 in select () at ../sysdeps/unix/syscall-template.S:81
* 1 Thread 0x76e65000 (LWP 10098) "pihole-FTL" 0x76f58964 in select () at ../sysdeps/unix/syscall-template.S:81