Анализ дампа ядра Solaris

Question

Я использую pstack для анализа файлов дампа ядра в Solaris

Как еще можно проанализировать дамп ядра из соляриса?

Какие команды можно использовать для этого?

Какая другая информация будет доступна на свалке?

Answer 1

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

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

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

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

См. Документация MDB и Документация DBX . Карта быстрого доступа GDB также полезна, если вы знакомы с основами GDB.

Answer 2

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

Для dbx рецепт:

% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread t@3
(dbx) where

Answer 3

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

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

Answer 4

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

Answer 5

Я нашел dbx на моей коробке Solaris x86 в

/opt/SUNWspro/bin/dbx

Ура! * * 1004

Answer 6

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

dbx [имя_файла_исполняемого_файла] [coredump_file_name]

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

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

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

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

Веселитесь.

Answer 7

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

Answer 8

GDB может быть использован.

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

http://sourceware.org/gdb/

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

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

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