GDB: Ctrl + C не прерывает процесс, как обычно, а завершает программу - PullRequest
27 голосов
/ 02 мая 2011

Обычно, когда вы запускаете программу через GDB, вы можете нажать Ctrl + C, чтобы прервать ее, например, если она застряла в бесконечном цикле и вы хотите получить обратную трассировку.

Я отлаживаю программу(xmms2d, как это происходит), но только в этой программе, когда я нажимаю Ctrl + C, она обрабатывается так, как будто GDB не работает - программа завершает работу чисто, а затем GDB сообщает мне, что программа завершилась нормально.

Каквернуть обычное поведение GDB, где Ctrl + C прерывает программу?Или есть другой способ вызвать такую ​​же реакцию в GDB, как это обычно делают Ctrl + C?

Ответы [ 5 ]

24 голосов
/ 22 июня 2011

Держу пари, что xmms2d использует sigwait () для обработки сигналов, что нарушает способность GDB ловить CTRL-C.См. https://bugzilla.kernel.org/show_bug.cgi?id=9039

У меня есть идея для обхода проблемы, прочитав Продолжить отладку после неудачного утверждения в Linux? - когда я готов к взлому в gdb, я запускаю команду "kill"-TRAP "из другого окна терминала.

7 голосов
/ 02 августа 2014

В приглашении GDB вы можете сделать «обработать остановку SIGINT», чтобы GDB ловил CTRL-C

4 голосов
/ 07 января 2017

У меня была та же проблема, вызванная обработчиками сигналов SDL, которые мешают работе GDB.Одно из решений, которое я нашел, чтобы обойти это при запуске gdb:

start
call sigignore(2)
continue

Теперь все CTRL-C будут игнорироваться приложением.

Если вы attach к некоторому процессу и хотите восстановить егов исходное состояние после отладки, вы можете сделать это:

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

И когда вы закончите:

call signal(2, $oldcallback)
detach
0 голосов
/ 20 октября 2018

Обратите внимание, что запуск GDB под rlwrap нарушает его способность правильно перехватывать ^C.Если вы делаете это, попробуйте запустить его без rlwrap.

0 голосов
/ 04 декабря 2013

Вы можете изменить цель ввода / вывода GDB, используя следующую команду:

gdb -tty = /dev/tty1
...