Мне нужно найти точку в моем коде пользователя, которая приводит к сбою моего ядра

Question

У меня большая система, которая делает мой системный сбой тяжелым. Когда я загружаюсь, у меня даже нет coredump. Если я войду в каждую строку, казнить, пока моя система не выйдет из строя. Я найду этот злой код.

Могу ли я записать каждую строку исходного кода в GDB в файл?

UPDATE:

хорошо, я нашел ошибку. Это было противно. Приложение, которое я запустил, не убрать систему. Узнав о проверке coredump с помощью mdb и некотором шаге gdb, я обнаружил, что системный вызов, вызывающий дамп, не был реализован. Обновление системы до последнего ядра решит мою проблему. Всем спасибо.

МОЙ УРОК:

убедитесь, что вы знаете, какой процесс вызывает coredump. Это не всегда тот, который вы начали.

Answer 1

Вы не можете разумно отслеживать каждую строку вашего источника, используя GDB (слишком медленно). Кроме того, сбой системы, скорее всего, является результатом системного вызова, и libc, вероятно, выполняет системный вызов от вашего имени. Даже если вы найдете строку приложения, которая вызвала сбой ОС, вы все равно ничего не знаете.

Вы должны начать с выяснения, какая ОС дает сбой. Для Linux вы можете попробовать следующие подходы:

strace -fo trace.out /path/to/app

После перезагрузки trace.out будет содержать системные вызовы, которые приложение выполняло непосредственно перед сбоем. Если вам повезет, вы увидите последний системный вызов смерти, но я бы на это не рассчитывал.

В качестве альтернативы попробуйте воспроизвести сбой на пользовательском режиме Linux или на ядре с KGDB , скомпилированным в.

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

Answer 2

Звучит как хитрая маленькая проблема.

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

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

Говоря о дампах ядра, убедитесь, что у вас нет ограничения на размер дампа ядра (man ulimit.)

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

И не паникуйте. Вы умнее жука - вы его найдете.

Answer 3

Пожалуйста, уточните вашу проблему: какая часть системы дает сбой?

Это приложение? Если да, то какое приложение? Это приложение, которое вы написали сами? Это приложение, которое вы получили в другом месте? Можете ли вы получить чистое прерывание, если вы используете отладчик? Можете ли вы получить обратную трассировку, показывающую, какие функции вызывают раздел кода, который дает сбой?

Это новый аппаратный драйвер? Это основано на более старом драйвере? Если так, что изменилось? Это основано на паспорте производителя? Этот лист данных самый последний и самый правильный?

Это где-то в ядре? Какое ядро?

Что такое ОС? Я предполагаю, что это Linux, видя, что вы используете отладчик GNU. Но, конечно, это не обязательно так.

Вы говорите, что у вас нет coredump. Вы включили coredumps на своей машине? Большинство систем в настоящее время не поддерживают coredumps по умолчанию.

Что касается записи выходных данных GDB, у вас может быть некоторый успех, но это зависит от того, где проблема в том, будете ли вы регистрировать правильный вывод перед тем, как система выйдет из строя. Существует много задержек при записи на диск. Вы можете не успеть вовремя.

Answer 4

Я не знаком с способом gdb, но с помощью windbg можно подключить отладчик к ядру и удаленно управлять отладчиком через последовательный кабель (или firewire) из второго отладчика. Я почти уверен, что GDB имеет аналогичные возможности, я мог бы быстро найти некоторые подсказки здесь: http://www.digipedia.pl/man/gdb.4.html