анализ основного файла

Question

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

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

EDIT: общие библиотеки той же версии, поэтому не стоит беспокоиться о том, что они не помещаются в хранилище shaerd, поэтому он может быть доступен как из Linux 5 и Linux 3.

спасибо.

Answer 1

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

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

Answer 2

Вы задали подобный вопрос и принял ответ, конечно же сами здесь: Analyzing core file of shared object

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

Для начала началось небольшое учебное пособие here.

EDIT:

Предполагая, что вы хотите знать, как анализировать файл дампа с помощью GDB на Linux, как ваш вопрос немного неясно.

Answer 3

Вы всегда можете запустить gdb -c /path/to/corefile /path/to/program_that_crashed. Однако, если program_that_crashed не имеет отладочные Infos (т.е. не был составлен и связаны с этим флагом -g GCC/LD) CoreDump не то, что полезно, если вы не злостной отладки эксперт ;-)

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

Кроме того, путь, в котором генерируется 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, чтобы открыть файл ядра

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. Со всеми адресами инструкции и количеством команд в нативной функции будет diff, а там, где отладчик получает goofed вверх, и, возможно, может показать вам неправильные данные для анализа. Поэтому всегда полезно анализировать ядро ​​на той же платформе или если вы можете скопировать всю необходимую общую библиотеку на другую машину и установить путь через set solib-absolute-prefix.