Ценность дампов памяти

#cpp

Есть много утилит для всяких исследований кода. Прочитал несколько мнений на счёт
того что выявление бага кода лучше делать через такие инструменты. Зачем тогда нам
нужен дамп памяти? Можно ли из этого дампа извлечь нечто такое, что нельзя получить
используя разные утилиты?
    

Ответы

Ответ 1

А как можно еще проанализировать ошибку, которая произошла у пользователя ПО?
Пользователь ПО обычно посылает разработчику core dump и с его помощью можно продиагностировать
ошибку.

Понадобится executable с включёнными символами и полностью идентичный с тем, для
которого был создан core dump. Затем можно запустить дебаггер:

gdb /path/to/executable /path/to/coredump


Далее, командой bt full можно получить backtrace с момента возникновения ошибки.
То есть, можно увидеть цепочку выполнения функций со значениями переданных им аргументов.

Подробнее как двигаться от функции к функци и просматривать значения переменных смотрите:
info gdb.


Ответ 2

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

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

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

Для обеспечения нормальной работы ПО используется множество различных методов синхронизации,
начиная хитрой архитектурой, которая даёт возможность безблокировочного доступа к общим
данным, и заканчивая мьютексами в некоторых ситуациях, когда архитектура не помогла.

Программа написана на C++ и содержит более 800 тысяч строк кода. Код писался далеко
не одним человеком. Многие участки кода крайне сложны для понимания человеком, который
только что его увидел. Однако ПО работает довольно успешно, и поэтому вариант "переписать
всё с нуля" категорически неприемлем (это заняло бы слишком много ресурсов).

И вот, как назло в самый разгар розыгрыша тендера на поставку, приходит сообщение
от отдела поддержки - программа в продакшене самопроизвольно падает в случайные моменты
времени, если запустить - примерно через минуту она ложится.

Что делает отдел разработки? Конечно, собираем проект в отладке и садимся за gdb
. Но, как это часто бывает, в отладочной версии программа даже намёков не подаёт на
какие-либо проблемы. Более того - на рабочей машине запустили под отладчиком, она даже
не думала падать.

Различные статические и динамические анализаторы проблем не выявили (например, valgrind
показал, что всё чисто).

И тут нас спасли дампы. Конечно, они не совсем нас спасли, потому что дамп нужно
ещё проанализировать. С момента получения примерного намёка на причину проблемы до
полного её решения прошла примерно неделя.

Что мы сделали. Были получены несколько дампов с упавшей программы, и затем они были
тщательно изучены. На основе этого были искуственно смоделированы условия, при которых
программу удалось уронить в режиме отладки в лаборатории, ну а дальше уже отладка на
горячую в gdb (она кстати была совсем не простой, потому что по сути отладчик ничего
не показал, кроме места слёта, там был уничтожен стек, но это уже не относится к вопросу,
поэтому я опущу подробности).

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

PS. Чисто поржать - по итогам фикса бага мною был сделан самый маленький в истории
проекта коммит, из более 800 тысяч строк кода было изменено всего... 1 символ .

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