Debugging

Без плана правка “по-быстрому” превращается в три часа блуждания по коду и два новых бага взамен старого. Проблема не в скорости мышления, а в отсутствии зафиксированных шагов, которые можно откатить. Skill writing-plans перед сложной задачей выписывает шаги, риски и откат: ошибку на шаге 3 видно сразу, а не после того, как она потянула шаг 7. Skill systematic-debugging работает похоже для багов: гипотеза → проверка → вывод, вместо “поменяю тут, авось заработает”. ...

Процесс завис или ведёт себя странно, а логов нет — strace -p PID цепляется к уже запущенному процессу и показывает каждый системный вызов в реальном времени. Флаг -f заставляет следить и за форкнутыми дочерними процессами — без него, например, не увидишь вызовы воркеров nginx или дочерних процессов после fork(). Полный трейс — простыня строк, поэтому обычно сразу фильтруют по типу вызовов: strace -f -e trace=network -p 1234 strace -f -e trace=open,openat -p 1234 Когда важна не последовательность, а картина в целом — какие вызовы процесс делает чаще всего и сколько на них тратит времени — вместо полного трейса берут сводку: ...

Когда сервис падает, а логов недостаточно, следующий шаг — gdb. Не обязательно быть C-разработчиком: базовых команд хватает, чтобы вытащить стек вызовов и переменные на момент краха. gdb -p $(pgrep myapp) # подключиться к живому процессу gdb --args ./myapp --config prod.conf (gdb) bt # backtrace — стек вызовов (gdb) info locals # переменные текущего фрейма (gdb) frame 2 # переключиться на фрейм (gdb) print my_var (gdb) continue Для уже случившегося краха без живого процесса — gdb ./myapp core.12345: bt покажет строку и стек на момент сигнала. Без -g при сборке символов нет, bt покажет только адреса — но иногда и этого хватает понять, в какой библиотеке крах. ...

Динамически слинкованный бинарник не содержит код библиотек внутри — при запуске загрузчик находит .so-файлы по путям из кэша. ldd, ldconfig и LD_PRELOAD управляют этим процессом, пригождаются при error while loading shared libraries. # какие .so нужны бинарнику и откуда они реально берутся ldd /usr/bin/nginx # обновить кэш путей после установки новой библиотеки в нестандартный путь ldconfig ldconfig -p | grep libssl # проверить, что библиотека в кэше # подменить библиотеку на лету, без пересборки бинарника LD_PRELOAD=/opt/libs/libfake.so ./app LD_PRELOAD удобен для отладки и быстрых хаков без правки исходников, но тем же механизмом пользуются руткиты — лишняя строка в выводе ldd повод проверить /etc/ld.so.preload. ...