Анализ дампа Solaris Core

Вы можете использовать модульный отладчик Solaris, mdb или dbx. mdb поставляется с пакетом SUNWmdb (или SUNWmdb x для 64-битной версии).

Основной файл - это изображение вашего текущего процесса в момент его разбивки.

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

В недавних версиях Solaris вы можете настроить, что основной файл будет содержать с помощью команды coreadm; например, вы можете иметь сопоставленные сегменты памяти, к которым был присоединен процесс.

Обратитесь к документации MDB и dbx . Карта GDB quick reference также полезна, когда вы знаете основы GDB.

Я предполагаю, что любой ответ на этот вопрос должен начинаться с простого рецепта:

Для dbx рецепт:

% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread [email protected]
(dbx) where

Если дамп ядра - это программа, которую вы написали или создали, используйте любой отладчик, который вы обычно используете для отладки запущенного приложения. Все они должны иметь возможность загружать файлы ядра. Если вы не придирчивы к отладчикам, и вы используете Solaris, я бы порекомендовал dbx. Это поможет получить последнюю версию Sun Studio с патчами, а также последнюю версию Sun Studio. Также очень полезно, если вы можете загрузить основной файл в отладчик в той же системе, где был создан основной файл. Если код в библиотеках отличается от того, когда был создан основной файл, трассировка стека не будет полезна, когда она будет проходить через библиотеки. Отладчики также используют вспомогательные библиотеки ОС для понимания структур данных компоновщика libthread и runtime, поэтому, если вам нужно загрузить основной файл на другой компьютер, вы должны убедиться, что вспомогательные библиотеки, установленные в ОС, соответствуют структурам системных данных в ОС. Вы можете узнать все, что вы никогда не хотели знать об этих системных библиотеках в белой статье, написанной несколько лет назад.

Ссылка

Можно использовать GDB.

Он может дать вызов, который был предпринят перед дампом.

Ссылка

Ссылка

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

В прошлом работал отлично для меня.

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

Прикрепите образ процесса с помощью отладчика dbx:

dbx [executable_file_name] [coredump_file_name]

Важно, чтобы никаких изменений в исполняемом файле не было, поскольку ядро ​​было сброшено (т. е. оно не было восстановлено).

Вы можете увидеть трассировку стека, чтобы увидеть, где программа разбилась с помощью команды dbx «где».

Вы можете перемещаться вверх и вниз по стеку с помощью команд «вверх» и «вниз» или переходить к точной кадре стека с «frame [number]» с номерами, отображаемыми на выходе «где».

Вы можете распечатать значение переменных или выражений с помощью команды «print [expr]».

Удачи.

Я нашел dbx на моей панели Solaris x86 на

/opt/SUNWspro/bin/dbx

Ура!

Я бы предложил сначала попробовать gdb, так как легче понять основные задачи, чем родные отладчики Solaris, на мой взгляд.