Отладка программ в Linux с помощью GDB — основы и шпаргалка

Что такое отладчик и зачем он нужен

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

Краткое определение: отладчик — инструмент для контроля и пошагового исполнения программы с возможностью инспекции состояния.

Установка GDB

GDB (GNU Debugger) — основной отладчик для Linux. На многих системах он уже установлен (или установлена урезанная версия gdb-minimal). Установить вручную можно так:

sudo apt-get install gdb

Важно: используйте пакетный менеджер вашей системы (apt, dnf, pacman и т.д.).

Пример: подготовка программы с отладочной информацией

Создадим простой пример на C. Откройте файл:

nano hello10.c

Вставьте следующий код:

#include 

int main()
{
    int i;
    for (i = 0; i < 10; i++) {
        printf("hello %d\n", i);
    }
    return 0;
}

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

gcc -g -o hello10 hello10.c

Флаг -g не включает оптимизации; если вы одновременно используете -O2/-O3, поведение отладки может отличаться (переменные могут быть оптимизированы компилятором).

Запуск GDB и базовые команды

Запустить отладчик для скомпилированной программы:

gdb hello10

Если сразу выполнить run, программа выполнится и завершится до того, как вы успеете что-то сделать. Чтобы остановить выполнение в нужном месте, установите точку останова (breakpoint). Самый простой вариант — остановиться в функции main:

break main

Запустите программу:

run

Отладчик остановится на первой исполняемой строке. Для перехода к следующей строке используйте команду next (или n):

next
n
next

Проверить значение переменной можно командой print:

print i

Пример использования в цикле:

next
next
next
print i

Изменение переменных во время выполнения

Можно изменить значение переменной командой set var:

set var i = 10
print i
next

Если вы установите i = 10, то при следующем выполнении строки цикла условие i < 10 станет ложным и цикл завершится.

Разница между next и step

• next (n) — выполнить текущую строку, но не заходить внутрь вызовов функций (функция выполнится целиком).
• step (s) — выполнить шаг и зайти внутрь вызываемой функции, если есть.

Наблюдение за изменением переменной (watch)

Watch позволяет остановить программу при изменении указанной переменной. Например:

watch i
continue

Команда continue возобновляет выполнение до следующей точки останова или до срабатывания наблюдаемого условия.

Завершение сессии отладки

quit

Быстрый справочник команд GDB (шпаргалка)

• run — запустить программу
• break <место> — поставить точку останова (например, break main, break file.c:25)
• delete — удалить точки останова
• continue — продолжить выполнение
• next / n — шаг по исходному коду, не заходя в функции
• step / s — шаг с заходом в функции
• print — вывести значение выражения
• set var = — изменить переменную
• watch — наблюдать изменение выражения и останавливаться
• info breakpoints — показать все точки останова
• backtrace / bt — стек вызовов
• frame — перейти к фрейму в стеке
• list — показать исходный код вокруг текущей строки

Важно: синтаксис выражений в print совпадает с синтаксисом C; можно вычислять простые выражения.

Ментальные модели и эвристики для отладки

• Сначала локализуйте проблему: воспроизводится ли ошибка всегда? В каком модуле? На каком входе?
• Сужайте область поиска, ставьте точки останова и наблюдайте только релевантные переменные.
• Предполагаемая причина → проверка гипотезы: измените состояние, посмотрите, изменилось ли поведение.
• Отделяйте ошибки логики (инварианты, условия) от ошибок среды (сборка, библиотеки, конфигурация).

Альтернативные подходы и когда их использовать

• printf-отладка: простая и работает в средах без отладчика; полезно для быстрых проверок и параллельных приложений.
• IDE-интегрированные отладчики (Visual Studio Code, CLion): удобный интерфейс, точки останова, просмотр переменных, но могут скрывать детали командной строки.
• LLDB: современный отладчик, часто используется на macOS и в средах LLVM.
• Администрирование и трассировка (strace, ltrace): для отладки системных вызовов и библиотечных вызовов.

Когда не работать с GDB: если проблема воспроизводится только в продакшене и отладчик изменяет поведение (Heisenbug). В таких случаях используют логирование и постмортем дампы (core dumps).

Мини-методология: пошаговый план отладки

1. Воспроизведите проблему стабильно.
2. Сузьте область: минимальный воспроизводимый пример.
3. Добавьте проверочные точки (break/watch) в предполагаемых местах.
4. Инспектируйте значения, compare с ожидаемыми (print).
5. Если нужно — измените переменные или вызовы, проверьте гипотезы.
6. Повторите, пока не найдёте причину; затем исправляйте и добавляйте тесты.

Ролевые чеклисты

Разработчик:

• Воспроизводимость: есть ли шаги для воспроизведения?
• Минимальный пример: можно ли выделить проблему в небольшом файле?
• Логирование и assertions: добавлены ли проверки состояния?
• Регресс-тесты: есть ли тест, который зафиксирует исправление?

QA / тестировщик:

• Подробные шаги: окружение, входные данные, ожидаемое поведение.
• Воспроизведение на чистой системе.
• Сбор дампов/логи и прикрепление к баг-репорту.

Операции/DevOps:

• Можно ли получить core dump? Настроен ли ulimit?
• Есть ли доступ к отладочной информации (символы)?

Критерии приёмки

• Ошибка воспроизводится на тестовом стенде по описанным шагам.
• После исправления тест, покрывающий проблему, проходит в CI.
• Логи и дампы добавлены к задаче для ретроспективного анализа.

Примеры тестов и проверки

• Смоделировать ввод, при котором цикл выполняется N раз, и проверить значения на контрольных точках.
• Проверить граничные условия (i = 0, i = 9, i = 10).
• Проверить поведение при оптимизациях компилятора (с флагами -O0 и -O2).

Дерево решений: какой метод отладки выбрать

flowchart TD
  A[Есть отладочная информация?] -->|Да| B[GDB/IDE]
  A -->|Нет| C[printf / логирование]
  B --> D{Проблема в системных вызовах?}
  D -->|Да| E[strace/ltrace]
  D -->|Нет| F[Использовать break/watch/step]
  C --> G{Нужна высокая точность?}
  G -->|Да| H[Добавить символы отладки и пересобрать]
  G -->|Нет| I[Доработать логи]

Часто задаваемые вопросы

Как получить стек вызовов в GDB?

Используйте команду backtrace или bt:

backtrace

Что делать, если переменные не видны в GDB?

Возможные причины:

• Программа скомпилирована без -g.
• Компонент скомпилирован с оптимизациями, которые убрали переменную. Попробуйте компилировать с -O0 -g.

Можно ли отлаживать многопоточные приложения?

Да. GDB поддерживает потоки, есть команды thread и info threads для управления потоками.

Риски и советы

Важно: использование отладчика может изменить поведение программы (например, тайминги). Для сложных гонок и Heisenbugs сочетайте отладчик с логированием и трассировкой.

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

Резюме

GDB даёт контроль над выполнением программы, позволяет ставить точки останова, смотреть и менять переменные, шагать по коду и наблюдать за изменениями. Это мощный инструмент для локализации багов, особенно в системном и низкоуровневом коде. Начните с простых команд (break, run, next, print) и постепенно добавляйте наблюдения (watch), стек вызовов (backtrace) и работу с фреймами.

Важно: комбинируйте GDB с другими методами (логирование, printf, strace, IDE) в зависимости от сценария.

Задайте вопросы в комментариях, если пример не работает в вашей среде — подскажем отладочные шаги.