анализ файла ядра

Question

Я использую Linux Redhat 3, может кто-нибудь объяснить, как это возможно, что я могу анализировать с gdb дамп ядра генерируется в Linux redhat 5?

я не жалуюсь :) но я должен быть уверен, что это всегда будет работать ...?

РЕДАКТИРОВАТЬ: общие библиотеки имеют одинаковую версию, так что не беспокойтесь об этом, они помещаются в хранилище Shaerd, поэтому к ним можно получить доступ как из linux 5, так и из linux 3.

спасибо.

Answer 1

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

gdb
 (gdb) exec-file <executable address>
 (gdb) set solib-absolute-prefix <path to shared library>
 (gdb) core-file <path to core file>

Причина, по которой вы не можете полагаться на это, заключается в том, что каждый процесс использует libc или системную общую библиотеку, которая обязательно будет иметь измененияот красной шляпы 3 до красной шляпы 5. Таким образом, все адреса команд и номера инструкций в нативной функции будут различаться, и там, где отладчик будет сбит с толку, и, возможно, может показать вам неверные данные для анализа.Поэтому всегда полезно проанализировать ядро ​​на той же платформе или если вы можете скопировать всю необходимую разделяемую библиотеку на другой компьютер и задать путь с помощью set solib-absolute-prefix.

Answer 2

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

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

Answer 3

Вы всегда можете запустить gdb -c /path/to/corefile /path/to/program_that_crashed. Однако, если program_that_crashed не имеет отладочной информации (т. Е. Не был скомпилирован и , связанный с флагом -g gcc / ld), coredump не очень полезен, если вы не специалист по отладке;)

Обратите внимание, что генерация core-файлов может быть отключена (и очень вероятно, что она отключена по умолчанию в большинстве дистрибутивов). Смотри man ulimit. Звоните ulimit -c, чтобы увидеть ограничение основных файлов, «0» означает отключено. Попробуйте ulimit -c unlimited в этом случае. Если установлен предел размера, размер coredump не будет превышать предельный размер, что может привести к обрезанию ценной информации.

Кроме того, путь, по которому генерируется coredump, зависит от / proc / sys / kernel / core_pattern. Используйте cat /proc/sys/kernel/core_pattern для запроса текущего шаблона. На самом деле это путь, и если он не начинается с /, то файл будет сгенерирован в текущем рабочем каталоге процесса. И если cat /proc/sys/kernel/core_uses_pid возвращает «1», то coredump будет иметь PID файла сбойного процесса в качестве расширения файла. Вы также можете установить оба значения, например, echo -n /tmp/core > /proc/sys/kernel/core_pattern заставит генерировать все coredumps в /tmp.

Answer 4

Я понимаю вопрос как:

как это возможно, что я могу проанализировать ядро, которое было произведено под одна версия ОС под другой версия этой ОС?

Только потому, что вам повезло (даже это сомнительно). Есть много вещей, которые могут пойти не так, если попытаться сделать это:

• цепь инструментов gcc, gdb и т. Д. быть разных версий
• общие библиотеки будут разные версии

так нет, на это не стоит полагаться.

Answer 5

Вы задали аналогичный вопрос и приняли ответ, конечно, самостоятельно здесь: Анализ файла ядра общего объекта

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

Существует небольшое руководство здесь , с которого можно начать.

РЕДАКТИРОВАТЬ:

Предполагая, что вы хотите знать, как анализировать файл ядра, используя gdb в linux, ваш вопрос немного неясен.