Дополнение к valgrind?
Я работал в течение последних нескольких недель, пытаясь разыскать действительно трудную ошибку, которая разрушает мое приложение. Во-первых, приложение отказывало на присваивании станд.:: строка, затем во время свободной из локальной переменной.
После тщательного контроля кода не было никакой причины его для катастрофического отказа в этих местоположениях; однако, это всегда отказывало при попытке освободить недопустимый указатель (т.е. указатель, который указал на недопустимую память). И я понятия не имею, почему этот указатель не указывал на правильное местоположение.
Я подозреваю, что проблема имеет отношение к проблеме повреждения памяти или какой-то проблеме повреждения указателя. Проблема состоит в том, что я еще не могу визуально разыскать его..... Я понятия не имею, где начать смотреть в коде, и существуют тысячи строк кода для прохождения через так, это не походит на реалистический подход к проблеме.
Таким образом в прибывает Valgrind...
Инструмент, что я зависел от много раз для нахождения проблем в рамках кода, который может привести к катастрофическому отказу этого типа. Однако на этот раз это подошло пустое врученный! Я не вижу ошибок в valgrind, когда проблема происходит и так следовательно причина для меня задающий этот вопрос.
Есть ли какие-либо другие приложения, которые могут дополнить valgrind, и справка находят проблемы в коде, который может вызвать упомянутый выше катастрофический отказ?
Спасибо!
8 ответов
Я предполагаю, что вы используете инструмент memcheck от valgrind, который это то, чем он знаменит. Поскольку вы уже используете valgrind, вы также можете попробовать запустить свою программу с помощью valgrind --tool = exp-sgcheck (ранее exp-ptrcheck ), который является экспериментальным инструментом, который предназначен для перехватить определенные типы ошибок, которые будет пропускать memcheck, включая проверки доступа к стеку и глобальным массивам, а также использование указателей, которые указывают на действительный объект, но не на объект, который был предназначен. Он делает это с помощью совершенно другого механизма, по сути отслеживая каждый указатель в памяти, а не отслеживая саму память, а также с помощью эвристики.
Имейте в виду, что это экспериментальный инструмент, но вы можете обнаружить, что он обнаруживает что-то важное. В настоящее время он еще не поддерживает OS X или процессоры других производителей.
По моему опыту, coverity и purify нашли такие ошибки, каких не нашел valgrind (на самом деле все нашли проблемы, которые не увидели другие).
Но иногда ни один инструмент не дает подсказки, и вам приходится копать дальше, добавлять инструментарий, играть с точками останова на "modify memory at address", пытаться просто повторить тестовый пример, который не работает, и так далее, чтобы найти первопричину. Это может быть очень болезненно.
По моему опыту, часто подобные проблемы возникают из-за переполнения кучи. Electric Fence - это относительно простой инструмент отладки распределения, который я люблю использовать. Его основное применение - это инструмент динамического анализа для проверки переполнения кучи, дополнение к "-fstack-protector-all", который проверяет переполнение стека.
Больше ссылок на материалы по efence.
Возможно ли какое-то повреждение стека? Если это так, попробуйте включить stack canaries с опцией -fstack-protector-all , предполагая, что вы используете g ++.
А кроме этого, устанавливали ли вы предупреждающие флажки, чтобы помочь идентифицировать подозрительный код?
Вы не указали платформу, но я могу порекомендовать Gimpel PC-lint как отличный инструмент статического анализа (не обманывайтесь названием!). Они также предлагают FlexeLint для других платформ, но у меня нет личного опыта работы с этим продуктом.
Вы пробовали использовать lint, flexlint или cppcheck? Это может помочь определить проблему.
Если вы знаете, какая область памяти повреждена, пытались ли вы пометить эту память как защищенную. Это может замаскировать вашу проблему и совсем не помочь, но если он по-прежнему вызывает сбой, точка, в которой была изменена память, поможет решить вашу проблему.
Если valgrind может определить, что неверный указатель передается в free () , вы можете попробовать запустить программу под DDD, который может установить аппаратное наблюдение за ячейкой памяти и остановить программу, когда она получает плохая стоимость. Если указатель сильно меняется, вам, возможно, придется написать некоторый код вокруг malloc и free, чтобы отслеживать, какие значения хорошие и плохие.
На мой взгляд, использование отладчика с возможностями "обратной отладки" может помочь. Вы могли бы чтобы сделать шаг назад во времени и, надеюсь, выяснить, в чем был реальный источник проблемы.
Вот пара ссылок:
http://www.gnu.org/software/gdb/news/reversible.html
http://undo-software.com/ (который очевидно, бесплатна для некоммерческих приложений)