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

Ответ 1

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

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

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

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

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

Ответ 2

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

http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html

Ответ 3

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

Для dbx рецепт:

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

Ответ 4

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

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

http://sourceware.org/gdb/

http://en.wikipedia.org/wiki/GDB

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

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

Ответ 5

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

Ответ 6

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

dbx [executable_file_name] [coredump_file_name]

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

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

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

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

Удачи.

Ответ 7

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

/opt/SUNWspro/bin/dbx

Ура!

Ответ 8

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