Как Вы используете gdb для отладки кода?

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

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

В целом Вы находите что-то, что не является, как это должно быть и работать назад, пока Вы не понимаете почему.

Самое очевидное является самым полезным: Установка точки останова на функциональном или номере строки и обходе через строку кода с методической точностью.

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

gdb> p show_my_struct(struct)

My custom display of Foo:
   ...

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

gdb> watch foo
Watchpoint4: foo
gdb>

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

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

gdb <название программы> <базовый файл>

Например:

gdb a.out ядро

После выполнения этой команды на базовом файле gdb скажет Вам, как завершенная программа и отображается, где в программе ошибка произошла:

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

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

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

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

Можно также использовать Geany.

Основной, но очень полезный - Использование текст gui с опцией - tui.

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

Я не уверен, насколько опытный OP, таким образом:

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

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

Хотя не gdb, они связаны: я лично нашел, что разрушение сложных строк для помощи в определении, какие операторы являются erroring, помогает.

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

Используйте ddd, визуальный фронтенд для gdb. Это позволяет Вам сделать вещи легко несколькими щелчками мышью и визуализировать, как код работает, плюс в консоли отладки, у Вас есть intercative gdb.