Дебаг систем в UNIX

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

После лекции вы сможете

отличить код завершения, сигнал и core dump
собрать C++-программу с отладочной информацией и исследовать живой процесс или его дамп
найти в трассе системных вызовов конкретную ошибку доступа к файлу
подобрать проверку для ошибки памяти, гонки данных и неопределённого поведения
объяснить, что показывает профиль CPU, а что он не доказывает
собрать минимальный отчёт об ошибке с воспроизводимым входом и подтверждённой причиной

Определяем симптомы и выдвигаем гипотезы

«Программа не работает» — практически ничего не говорит нам. Сначала зафиксируйте, что именно произошло, в каком окружении и можно ли это повторить. Для решения проблем полезны время, версия сборки, команда запуска, входные данные, PID, код завершения и сообщения журнала. Каждое наблюдение должно помогать отличать одну гипотезу от другой.

Симптом	Первое наблюдение	Следующий инструмент
Процесс завершился с ошибкой	Сообщение, код завершения, сигнал, журнал	GDB/LLDB, core dump, санитайзер
Процесс работает, но завис	PID, загрузка CPU, состояние потоков	Отладчик для стеков потоков; strace при ожидании системного вызова
Не найден файл или отказано в доступе	Точный путь, пользователь, права, рабочий каталог	strace на Linux
Результат неверен	Минимальный вход и ожидаемый результат	Логи, точки останова, тест, статический анализ
Программа медленная	Сценарий нагрузки и измерение времени	perf на Linux, профилировщик платформы

Код завершения — число, которое процесс возвращает родителю. В shell $? содержит статус последней команды. По распространённому соглашению Bash завершение из-за сигнала отражается как 128 + номер сигнала; это представление shell, а не «код возврата» самого процесса. В отчёте лучше назвать сигнал, а не полагаться на одно число. Команда kill PID по умолчанию посылает SIGTERM: она сама по себе не означает ни принудительное убийство через SIGKILL, ни создание дампа.

Живой процесс и core dump

Core dump — снимок состояния процесса при аварийном завершении: регистры и сведения о потоках, части адресного пространства и другая информация, зависящая от ОС и настроек. Может возникнуть при сигнале, действие которого — создание дампа, например SIGSEGV, SIGABRT или SIGQUIT. SIGKILL дамп не создаёт. Файл не гарантирован: влияют лимиты, конфигурация ядра, обработчик дампов, права и доступное место.

Сообщение «core dumped» не гарантирует файл core в текущем каталоге.

На Linux проверяем:

ulimit -c
cat /proc/sys/kernel/core_pattern

ulimit -c unlimited снимает ограничение размера для текущего shell и запускаемых из него процессов, если жёсткий лимит это позволяет.

Дамп может включать пароли, токены, фрагменты запросов и другие данные из памяти. Храните его с ограниченным доступом и сроком хранения. Полностью «обезличить» произвольный дамп сложно.

Но как отлаживать процесс, который ещё не завершился?