Дополнение к Вальгринду?

Question

Последние несколько недель я работаю, пытаясь отследить действительно сложную ошибку, которая приводит к сбою моего приложения. Сначала происходит сбой приложения при присвоении std :: string, а затем при освобождении локальной переменной.

После тщательной проверки кода не было причин для его сбоя в этих местах; однако, он всегда падал при попытке освободить недопустимый указатель (то есть указатель, который указывал на недопустимую память). И я понятия не имею, почему этот указатель не указывал на правильное местоположение.

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

Итак, приходит Вальгринд ...

Инструмент, от которого я зависел много раз, чтобы найти проблемы в коде, которые могут привести к сбою этого типа. Однако на этот раз он пришел с пустыми руками! Я не вижу никаких ошибок в valgrind при возникновении проблемы, поэтому я и задаю этот вопрос.

Существуют ли другие приложения, которые могут дополнить valgrind и помочь найти проблемы в коде, которые могут вызвать сбой, упомянутый выше?

Спасибо!

Answer 1

Полагаю, вы используете инструмент memcheck от valgrind, которым он и славится. Поскольку вы уже используете valgrind, вы также можете попробовать запустить вашу программу через valgrind --tool=exp-sgcheck (ранее exp-ptrcheck), который является экспериментальным инструментом, предназначенным для обнаружения определенных типов ошибок, которые пропустит memcheck, включая проверки доступа для стековых и глобальных массивов, а также использование указателей, которые указывают на действительный объект, но не на тот объект, который был задуман. Это достигается за счет использования совершенно другого механизма, по существу отслеживающего каждый указатель в памяти, а не отслеживающего саму память, и с помощью эвристики.

Помните, что инструмент экспериментальный, но вы можете обнаружить, что он улавливает что-то существенное. В настоящее время он еще не поддерживает процессоры OS X или не-Intel.

Answer 2

По моему опыту, у укрывательства и очищения есть такие ошибки, которых не было у Вэлгринда (на самом деле все найденные проблемы, которые другие не видели).

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

Answer 3

По моему опыту, подобные проблемы часто возникают из-за переполнения кучи. Electric Fence - это относительно простой инструмент отладки распределения, который мне нравится использовать. Его основное назначение - инструмент динамического анализа для проверки переполнения кучи, дополнение к «-fstack-protector-all», которое проверяет переполнение стека.

Дополнительные ссылки на efence материал.

Answer 4

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

Вот пара ссылок:

http://www.gnu.org/software/gdb/news/reversible.html

http://undo -software.com / (что, очевидно, бесплатно для некоммерческих приложений)

Answer 5

Возможно ли какое-то повреждение стека? Если это так, попробуйте включить стек канареек с параметром -fstack-protector-all, при условии, что вы используете g ++.

Кроме этого, вы установили флажки предупреждений, чтобы помочь идентифицировать подозрительный код?

Answer 6

Вы не указали платформу, но я могу порекомендовать Gimpel PC-lint в качестве отличного инструмента статического анализа (не дайте себя обмануть!). Они также предлагают FlexeLint для других платформ, но у меня нет личного опыта использования этого продукта.

Answer 7

Если valgrind может определить неверный указатель, передаваемый на free(), вы можете попробовать запустить программу под DDD, который может установить аппаратную точку наблюдения в ячейке памяти и остановить программу, когда она получает неверное значение.Если указатель сильно меняется, вам, возможно, придется написать некоторый код вокруг malloc и бесплатно, чтобы отслеживать, какие значения являются хорошими и плохими.

Answer 8

Вы пытались использовать lint, flexlint или cppcheck. Это может помочь определить проблему.

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