Как Вы читаете segfault сообщение журнала ядра
Это может быть очень простым вопросом, я, пытаюсь отладить приложение, которое генерирует следующую segfault ошибку в kern.log
kernel: myapp[15514]: segfault at 794ef0 ip 080513b sp 794ef0 error 6 in myapp[8048000+24000]
Вот мои вопросы:
Есть ли любая документация относительно того, что является различными кодами ошибки на segfault, в этом экземпляре это - ошибка 6, но я видел ошибку 4, 5
Каково значение информации
at bf794ef0 ip 0805130b sp bf794ef0 and myapp[8048000+24000]?
До сих пор я смог скомпилировать с символами, и когда я делаю a x 0x8048000+24000 это возвращает символ, который является корректным способом сделать его? Мои предположения к настоящему времени следующие:
- SP = указатель вершины стека?
- IP = указатель команд
- в =????
- myapp [8048000+24000] = адрес символа?
2 ответа
Основываясь на моих ограниченных знаниях, ваши предположения верны.
SP= указатель стекаIP= указатель инструкцииMyApp [8048000 + 24000]= адрес
Если я отладки проблемы, я бы изменил код для производства Дамп сердечника или журнал A Backtrace в аварии. Вы также можете запустить программу (или прикрепить) GDB.
Код ошибки - это просто код ошибки архитектуры для неисправностей страницы и, похоже, является специфичной архитектурой. Они часто документируются в ARCH / * / MM / FILOS.C в источнике ядра. Моя копия Linux / arch / i386 / mm / difl.c имеет следующее определение для ERROR_CODE:
- бит 0 == 0 означает, что не найдена страница, 1 означает неисправность защиты
- бит 1 = = 0 Средства чтения, 1 означает, что напишите
- бит 2 == 0 означает ядро, 1 означает пользовательский режим
Моя копия Linux / arch / x86_64 / mm / dift.c добавляет следующее :
- бит 3 == 1 означает, что неисправность была инструкциями
Когда в отчете указывается на программу, а не разделяемую библиотеку
Выполните addr2line -e myapp 080513b (и повторите для других заданных значений указателя инструкций), чтобы увидеть, где происходит ошибка. Лучше получить сборку с отладкой и воспроизвести проблему в отладчике, таком как gdb.
Если это разделяемая библиотека
В части libfoo.so [NNNNNN + YYYY] , NNNNNN - это место, где библиотека была загружена. Вычтите это из указателя инструкции ( ip ), и вы получите смещение в .so неправильной инструкции. Затем вы можете использовать objdump -DCgl libfoo.so и искать инструкцию по этому смещению. Вы легко сможете определить, какая это функция, по меткам asm. Если .so не оптимизирован, вы также можете попробовать использовать addr2line -e libfoo.so .
Что означает ошибка
Вот разбивка полей:
адрес- место в памяти, к которому код пытается получить доступ (вероятно, что10и11- это смещения от указателя, который, как мы ожидаем, будет установлен на допустимое значение, но который вместо этого указывает на0)ip- указатель инструкции, т.е. где код, который пытается это сделать, живетsp- указатель стекаошибка- специфичные для архитектуры флаги; см.arch / * / mm / fault.cдля вашей платформы.