Как отладить ошибку сегментации, в то время как трассировка стека gdb заполнена "??"?

Ответ 1

Я программист на С++ для жизни, и я столкнулся с этой проблемой больше раз, чем я хотел бы признать. Ваше приложение разбивает ОГРОМНУЮ часть стека. Скорее всего, функция, которая повреждает стек, также сбой при возврате. Причина в том, что адрес возврата был перезаписан, и именно поэтому трассировка стека GDB перепутана.

Вот как я отлаживаю эту проблему:

1) Шаг, хотя приложение до сбоя. (Ищите функцию, которая сбой при возврате).

2) После того, как вы определили функцию, объявите переменную в ОЧЕНЬ ПЕРВОЙ ЛИНИИ функции:

int canary=0;

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

3) Положите переменный вахту на канарейку, шаг за шагом, а функция canary!= 0, то вы обнаружили переполнение буфера! Еще одна возможность поставить переменную точку останова для canary!= 0 и просто запустить программу в обычном режиме, это немного проще, но не все контрольные точки переменной IDE.

EDIT: Я разговаривал со старшим программистом в моем офисе и для того, чтобы понять, что ядро ​​дало вам, чтобы решить, какие адреса памяти у него есть. Один из способов выяснить эти адреса - посмотреть файл MAP для двоичного кода, который является читаемым человеком. Ниже приведен пример создания файла MAP с использованием gcc:

gcc -o foo -Wl,-Map,foo.map foo.c

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

Ответ 2

• Вы должны использовать некоторый отладчик для обнаружения, valgrind в порядке
• пока вы компилируете свой код, убедитесь, что вы добавили параметр -Wall, он заставит компилятор сообщать вам, есть ли какие-то ошибки или нет (убедитесь, что у вас есть какие-либо предупреждения в вашем коде).

ex: gcc -Wall -g -c -o oke.o oke.c
3. Убедитесь, что у вас также есть опция -g для создания отладочной информации. Вы можете вызывать отладочную информацию с помощью некоторых макросов. Следующие макросы очень полезны для меня:

__LINE__: указывает строку

__FILE__: указывает исходный файл

__func__: сообщает вам функцию

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

Надеюсь, это поможет

Ответ 3

TL; DR: в стеке выделяются чрезвычайно большие объявления локальных переменных в функциях, которые в некоторых комбинациях платформы и компилятора могут переполнять и повреждать стек.

Просто добавьте еще одну потенциальную причину этой проблемы. Я недавно отлаживал очень похожую проблему. Запуск gdb с файлом приложения и ядра приведет к результатам, например:

Core was generated by `myExecutable myArguments'.
Program terminated with signal 6, Aborted.
#0  0x00002b075174ba45 in ?? ()
(gdb)

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

void MyClass::MyMethod {
   ...
   char charBuffer[MAX_BUFFER_SIZE];
   ...

}

Бинго! Я обнаружил, что для MAX_BUFFER_SIZE установлено значение 10000000, поэтому локальная переменная 10 МБ выделяется в стеке!. После изменения реализации для использования shared_ptr и создания буфера динамически, неожиданно программа начала работать отлично.

Ответ 4

Попробуйте запустить отладчик памяти Valgrind.

Ответ 5

Чтобы подтвердить, был ли ваш исполняемый файл скомпилирован в режиме деблокирования, т.е. никаких символов отладки.... что могло бы объяснить, почему там? Попробуйте перекомпилировать с помощью -g switch, который включает в себя информацию об отладке и встраивает ее в исполняемый файл. Кроме этого, я не знаю, почему у вас есть "??"...

Ответ 6

Не совсем. Конечно, вы можете копаться в памяти и смотреть на вещи. Но без трассировки стека вы не знаете, как вы добрались до того, где вы находитесь, и каковы значения параметров.

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

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

Если у вас есть система Unix, "valgrind" - хороший инструмент для поиска некоторых из этих проблем.

Ответ 7

Я предполагаю, что, поскольку вы говорите: "Мой исполняемый файл содержит таблицу символов", которую вы скомпилировали и связали с -g, и что ваш двоичный файл не был удален.

Мы можем просто подтвердить это: strings -a | grep function_name_you_know_should_exist

Также попробуйте использовать pstack на ядре ans и посмотрите, лучше ли это сделать для вызова вызова. В этом случае это звучит так, как ваш gdb устарел по сравнению с вашей версией gcc/g++.

Ответ 8

Похоже, вы не используете идентичную версию glibc на своем компьютере, поскольку основной файл был тогда, когда он разбился о производстве. Получите файлы, выводимые с помощью "ldd./appname", и загрузите их на свой компьютер, затем скажите gdb, где искать;

set solib-absolute-prefix /path/to/libs