Как я могу отладить этот SIGSEV в GDB? - PullRequest
2 голосов
/ 23 июля 2010

Я создаю ранее работающий код, но получаю ошибку сегмента и не могу понять, что пошло не так. GDB ловит ошибку, но не указывает на очевидную причину. Строка источника, которую он показывает, является именем функции, поэтому она даже не входит в функцию. Если я посмотрю на разбор инструкции, она все еще устанавливает стек, так что, возможно, стек испорчен. Так как же мне пойти отладить это? Это в QNX 6.2, только для консоли GDB.

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56
56      tcMatrix tcMatrix::operator*(float64 anMultiplier)

0x816b820 <__ml>:       push   %ebp
0x816b821 <__ml+1>:     mov    %esp,%ebp
0x816b823 <__ml+3>:     sub    $0x13ac,%esp
0x816b829 <__ml+9>:     push   %edi
0x816b82a <__ml+10>:    push   %esi
0x816b82b <__ml+11>:    push   %ebx 

Ответы [ 6 ]

4 голосов
/ 24 июля 2010

Инструкция, по которой вы работаете, - push %edi.

Скорее всего, это означает, что у вас переполнение стека.

Одной из вероятных причин переполнения стека является бесконечная рекурсия. Если (gdb) where показывает бесконечный поток вызовов функций, это ваша проблема.

Если where показывает разумную последовательность вызовов, выполните info frame и up несколько раз, ища кадры с неоправданно большим размером.

Наконец, проблема может быть вызвана изменением среды выполнения, а не чем-либо в вашей программе. Я не уверен, что QNX эквивалентен ulimit -s, но возможно, что ваш предел стека просто слишком мал.

2 голосов
/ 24 июля 2010

После ответа занятого русского:

ulimit -s работает на QNX, но по умолчанию он не ограничен.

Я бы поэкспериментировал с

ldrel -S2M -L yourexecutablename

, чтобы настроить начальное распределение стека / лень, чтобы увидеть, повторятся ли coredumps.Вы также можете использовать флаг QCC -N, чтобы увеличить начальный размер стека.

1 голос
/ 25 августа 2015

QNX теперь, кажется, поддерживает valgrind (по крайней мере, начиная с 6.5):

http://community.qnx.com/sf/frs/do/viewRelease/projects.valgrind/frs.valgrind.valgrind_3_10

1 голос
/ 23 июля 2010

Указатель «this» выглядит испорченным - кажется, что 0x79b963c выключен, но это возможно в зависимости от того, как инициализируются объекты.Попробуйте

напечатать * this

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

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

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

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

1 голос
/ 23 июля 2010

Что-нибудь уместно, если вы делаете "bt" в gdb?

0 голосов
/ 23 июля 2010

Вы также можете попробовать valgrind'ing, что может дать больше информации.

...