Как просмотреть файл CoreDump?
Когда вы сообщаете об ошибке при сбое, ошибка сделана частной и файл CoreDump.gz. Документация Bug Triage гласит следующее:
Если в результате сбоя все еще есть вложение CoreDump.gz, невозможно автоматически получить полностью символическую трассировку стека и проверить наличие дубликатов.
Stacktrace.txt кажется читаемым человеком. Как я могу понять смысл трассировки стека. CoreDump с CoreDump.gz не кажется читаемым человеком. Что такое «полностью символическая трассировка стека»? В чем разница между «полностью символической трассировкой стека» Как просмотреть содержимое файла CoreDump? (попробовал «кот», но он не чист)
1 ответ
Coredump.gz - это (сжатая) память, доступная для программы, которая разбилась. Это двоичный файл.
Coredumps можно просмотреть, запустив «gdb»:
gdb --core=mycoredump
Конечно, вам все равно понадобится пакеты отладки, связанные с этим ядром.
Затем вы можете сгенерировать stacktrace с помощью:
(gdb) bt
для создания stacktrace текущего потока - без разрешения параметра - , или
(gdb) thread apply all bt full
для создания stacktrace всех потоков в coredump, с разрешением параметров.
stacktrace и fulltools показывают поток управления внутри программы. Для Python вершина stacktrace показывает самый старый вызов с самым последним внизу; для почти всего остального, верхний - это самый последний вызов, а нижний - самый старый.
Полная функция stacktrace не только покажет поток, но и значения параметра. Здесь мы обычно находим частные данные - например, вы видите функцию, называемую «validatePassword» с параметром «Пароль», а значение «MySecretPassword» ...
Stacktraces обычно только полезно, если пакеты отладки установлены (так что фреймы стека могут быть разрешены во что-то, что мы можем легко прочитать). Анализ stacktrace потребует наличия источников, которые были использованы для создания этого конкретного экземпляра программы.
-
1CoreDump - это двоичный файл, но как его просматривать? Stacktraces полезны только при установке пакетов отладки, тогда почему apport сообщает об этом иначе? – komputes 1 October 2011 в 00:33
-
2Файл CoreDump не предназначен для просмотра, он предназначен для использования в отладке в gdb. Вам нужно, чтобы машина работала с той же версией программного обеспечения (и всех зависимостей), генерируя крах и имея пакеты отладки, тогда вы можете использовать то, что Карлос написал выше, чтобы получить трассировку стека. – stgraber 1 October 2011 в 00:38
-
3Теперь о том, почему это все еще актуально для apport, это связано с тем, что apport имеет кучу «отступателей». которые захватывают ваш coredump, устанавливают пакеты отладки на ящике в DC и затем присоединяют полный stacktract к отчету об ошибке. – stgraber 1 October 2011 в 00:39
-
4Дополнительная документация: gnu.org/software/gdb/documentation – komputes 1 October 2011 в 00:52
-
5Дополнительная документация: unknownroad.com/rtfm/gdbtut/gdbtoc.html – komputes 1 October 2011 в 01:02