10.4. Посмертный анализ дампа

Что делать, если ядро аварийно завершает работу, хотя этого вы не хотели и поэтому командой config -g его не компилировали? Здесь не всё ещё потеряно. Не паникуйте!

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

Перейдите в каталог конфигурации ядра (/usr/src/sys/arch/conf) и отредактируйте ваш конфигурационный файл. Раскомментируйте (или добавьте, если она не существует) такую строку:

makeoptions    DEBUG=-g                #Build kernel with gdb(1) debug symbols

Перестройте ядро. Из-за изменения метки времени в Makefile будут перестроены и некоторые другие объектные файлы, например, trap.o. К некоторому счастью, добавление опции -g не изменит все и вся в генерируемом коде, так что в конце концов вы получите новое ядро с тем же кодом, что и сбоящее ядро, но с отладочной информацией. По крайней мере, вы можете сравнить старый и новый размеры ядер командой size(1). Если они не совпадают, то вам придется отказаться от вашей затеи.

Исследуйте дамп так, как это описано выше. Отладочной информации может не хватать в некоторых местах, как это можно видеть в трассировке стека примера выше, когда некоторые функции выводятся без номеров строк и списка аргументов. Если вам нужно больше отладочной информации, удалите соответствующие объектные файлы, снова перекомпилируйте ядро и повторите сеанс работы gdb -k, пока не получите достаточно подробную информацию.

Не гарантируется, что всё это будет работать, однако в большинстве случаев всё работает прекрасно.

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.