фатальная ошибка исчезла при запуске с GDB

Question

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

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

Это однопотоковая однопотоковая программа, такого раньше не было. Кто-нибудь может дать мне несколько комментариев? Спасибо.

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

Answer 1

Это только догадки, не глядя на код, но отладчики иногда делают это:

• Они инициализируют определенные вещи для вас
• Сроки выполнения операций изменены

У меня нет цитаты на GDB, но у меня есть одна на valgrind (если два делают дико разные вещи ..)

Моя программа нормально падает, но не работает под Valgrind, или наоборот. Что происходит?

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

То же самое относится и к GDB.

В большинстве случаев это не разница, но это может, особенно если ваша программа глючит.

Таким образом, истинная проблема, вероятно, в вашей программе.

Answer 2

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

Также возможно, что какое-то приложение имеет функцию защиты от отладки. Возможно, часть кода никогда не трогается при запуске внутри отладчика.

Один из способов проанализировать это с помощью дампа памяти. Который вы можете создать с помощью ulimit -c unlimited, затем запустить приложение, и когда ядро ​​будет выгружено, вы можете загрузить его в GDB с помощью gdb ./application ./core. Вы можете найти полезную запись здесь: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php

Answer 3

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