Недопустимая инструкция при компиляции с g ++ - PullRequest
Новая
       27

Недопустимая инструкция при компиляции с g ++

1 голос
/ 08 августа 2011

У меня проблема с тем, что программа C ++, работающая под Linux, скомпилированная с g ++, через некоторое время вызывает исключение недопустимой инструкции, и я получаю дамп ядра.Когда я выполняю обратную трассировку с использованием gdb, я получаю 

(gdb) bt
#0  0x005e18cf in ATL_dpotrfL () from /usr/lib/liblapack.so.3gf
#1  0x00000001 in ?? ()
#2  0xb786f2e8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

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

Теперь у меня вопрос: в чем проблема с программой?Является ли библиотека ошибочно скомпилированной (я скопировал ее несколько дней назад)?Или есть какая-то другая ошибка?

Я не определил никаких ассемблеров или подобных вещей.Только C ++.

Спасибо, Кристиан

Ответы [ 3 ]

7 голосов
/ 08 августа 2011

Это обычно означает разбитый стек.Особенно значение 0x00000001, которое, черт побери, вряд ли будет правильным адресом стека, поэтому я бы сказал, что вы переполнили буфер, выделенный стеком, и перезаписали адрес возврата.

2 голосов
/ 08 августа 2011

, как сказал другой, вы, вероятно, испортили свой стек.

Наиболее распространенные причины:

  • запись на неверный указатель (уже удален)
  • запись вне указанного пространства
  • объявление огромных локальных данных в стеке

Волшебный способ найти причину: 

valgrind  your_program  [args]

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

Тогда valgrind проверит вашу программу, покаон запускается (немного тормозит) и немедленно сообщает о вас, как только происходит запись, где это не должно происходить (например, в стеке)

2 голосов
/ 08 августа 2011

Что сказал DeadMG, плюс:

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

g++ -msse4 ...

и затем запустите устройство на процессоре Intel Atom, который не поддерживает набор инструкций SSE4. Авария не обязательно происходит, например, маловероятно, что 

int main () {}

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

Чтобы найти код разрушения стека, вы можете рассмотреть LINT, такой как cppcheck или аналогичный , Valgrind , старый добрый способ отладки printf / cout в режиме «разделяй и властвуй», или используя проверено выполнение STL.

...