Как вы используете GDB для отладки вашего кода?

Question

Как разработчик, как вы используете GDB для отслеживания ошибок в вашем коде? Какие приемы техники вы используете, чтобы облегчить свою жизнь?

Answer 1

Некоторые подсказки:

• использовать графический интерфейс (kdbg довольно хорошо, ddd по крайней мере лучше, чем gdb из командной строки, kdevelop имеет хороший интерфейс gdb, но имеет несколько bgs, nemiver выглядит также неплохо, но все еще в разработке)
• убедитесь, что у вас есть отладочные символы и исходный код для всех важных частей (ваш собственный код, а также некоторые системные библиотеки)
  • в RedHat вы можете установить пакеты -debuginfo, чтобы символы и исходный код волшебным образом отображались в отладчике - это действительно здорово, потому что вы можете просматривать вызовы функций libc и т. Д.
  • в Debian / Ubuntu вы можете установить пакеты -dbg для получения символов; установка соответствующих исходных файлов для системных пакетов кажется сложной, хотя
• Я склонен добавлять вызовы assert () и abort () в местах, которые не должны быть достигнуты, или в местах, которые я хочу изучать (какая-то тяжелая точка останова)
• в идеале вызовы assert () или abort () должны быть заключены в некоторый метод или макрос, который включает их только в выпусках отладки, или, что еще лучше, включает их, только если установлен определенный env var
• установить обработчик сигналов для SIGSEGV и SIGABRT; лично я проверяю, установлен ли определенный env var перед установкой обработчиков; и в обработчике я выполняю жестко закодированную внешнюю команду, которая обычно находится где-то в ~ / .local / bin /; эта команда может затем запустить kdbg и прикрепить его к аварийному приложению. Вуаля, отладчик появляется в тот момент, когда ваше приложение делает что-то плохое.
• Если вы используете модульные тесты, вы также можете подключить отладчик всякий раз, когда не удается выполнить тестовый случай, чтобы затем проверить приложение.

Answer 2

Одной из особенно полезных функций gdb является его способность проверять конечное состояние программы, которая потерпела крах.

Чтобы проверить аварийный дамп (или файл ядра, как его чаще называют), запустите gdb следующим образом:

gdb <имя-программы> <файл-ядра>

Например:

gdb a.out core

После запуска этой команды в основном файле GDB сообщит вам, как программа завершилась, и покажет, где в программе произошла ошибка:

Program terminated with signal 11, Segmentation fault.
#0  0x08048364 in foo () at foo.c:4
4         *x = 100;

В приведенном выше примере вы можете видеть, что программа завершилась с ошибкой сегментации при попытке присвоить значение указателю. Набрав backtrace (или bt или где ) в приглашении GDB, вы можете просмотреть полную обратную трассировку программы:

(gdb) backtrace
#0  0x08048364 in foo () at foo.c:4
#1  0x0804837f in main () at foo.c:9

В этот момент вы знаете, что main(), вызванные foo() и foo(), потерпели крах в строке 4 при попытке присвоить значение *x. Много раз, это предоставляет достаточно информации, чтобы позволить вам исправить ошибку.

Answer 3

В общем, вы находите что-то не так, как должно быть, и работаете в обратном направлении, пока не поймете почему.

Наиболее очевидным является наиболее полезное: установка точки останова для функции или номера строки и прохождение кода по строке.

Другой полезный совет - иметь функции show для всех ваших структур / объектов, даже если они никогда не использовались в вашей программе, потому что вы можете запускать эти функции из gdb:

gdb> p show_my_struct(struct)

My custom display of Foo:
   ...

Точки наблюдения тоже могут быть очень удобны, но могут сильно замедлить вашу программу. Они нарушают поток при изменении значения переменной или адреса.

gdb> watch foo
Watchpoint4: foo
gdb>

Answer 4

Основной, но очень полезный - используйте текстовый графический интерфейс с параметром -tui.

Answer 5

Я много занимаюсь разработкой параллельных программ, поэтому я обнаружил, что использование простой оболочки в python / ruby, которая позволяет мне подключить gdb ко всем процессам на всех узлах и общаться со мной, чрезвычайно полезно ( не нашел лучшего способа, если кто-нибудь знает, не взломать нить, хотя ...)

Я не уверен, насколько опытен ОП, поэтому:

Документы GDB довольно хороши и охватывают все. Первая глава - хорошее введение во все основы.

http://www.gnu.org/software/gdb/documentation/

Хотя это не GDB, они связаны: Я лично обнаружил, что помогает разбить сложные строки, чтобы определить, какие операторы являются ошибочными.

Кроме того, Valgrind (http://valgrind.org/) действительно хорош / полезен для преодоления переполнения буфера и тому подобного (мне не повезло с gdb для этого.

Answer 6

Вы также можете использовать Geany .

Answer 7

Используйте DDD, визуальный интерфейс для GDB. Это позволяет вам делать вещи с помощью нескольких щелчков мыши и визуализировать, как работает код, плюс в консоли отладчика у вас есть интерактивный GDB.