Повреждение кучи не обнаружено Valgrind или Electric Fence. Должен ли я быть подозрительным? (C++)
Я недавно столкнулся с моей первой битвой (решённой) с кучей коррупции. На моей машине linux дома код преступника завершается без ошибок, используя valgrind и electric-fence(с помощью gdb). Тем не менее, на компьютере с Windows в нашей лаборатории я постоянно получаю сообщение об ошибке, связанной с повреждением кучи, от VS, описанное в моей публикации.
Удивительно (или, по крайней мере, необычно), что valgrind и электрический забор не обнаружат такой проблемы? Кто-то еще упомянул возможную похожую ошибку, которая ускользнула от Valgrind в ответе здесь. Какие могут быть причины, по которым эти инструменты не будут обнаружены этими инструментами? Есть ли основания сомневаться в том, что ошибка на самом деле является кучей коррупции?
Обновление: Как упоминалось в посте, описывающем исходную проблему, я обнаружил, что проблема была в том, что указатели на элементы в std::vector стали плохими. Замена векторов на std::list (на которые указатели не становятся недействительными при добавлении новых элементов) исправила проблему. Итак, возвращаясь к моему вопросу о том, почему valgrind не обнаружил проблему, я спрашиваю, есть ли какие-либо рекомендации о том, как избежать подобной ситуации в будущем, а именно о проблеме с памятью, которая не обнаруживается valgrind, которая является одной из моих любимые инструменты. Очевидно, что было бы лучше понять, как работает STL. Возможно, мне нужно быть более настойчивым с утверждением в моем программировании и т. Д.
3 ответа
Таким образом, очевидная причина того, что Valgrind не смог обнаружить ваше повреждение кучи, заключается в том, что повреждение вообще не произошло с реализацией GCC STL (т. Е. Не было ошибки для обнаружения).
К сожалению, Valgrind работает на гораздо более низком уровне, чем STL, и поэтому многие ошибки остаются незамеченными. Например:
std::vector<int> v;
v.push_back(1);
v.push_back(2);
v.resize(0);
v[1] = 42; // Oops. Out of bounds access, but Valgrind is silent
К счастью, GCC STL имеет специальный режим отладки, предназначенный для решения многих подобных проблем. Попробуйте создать свой оригинальный код с -D_GLIBCXX_DEBUG, Вероятно, он поймает исходную проблему и может обнаружить больше проблем, о которых вы еще не знаете.
Вы не понимаете, что такое кучная коррупция. В частности, утечки памяти не являются повреждением кучи.
Утечка памяти, о которой сообщает Parallel Studio, также кажется фиктивной и, скорее всего, будет ошибкой в Parallel Studio, чем в вашей программе.
Если вы получаете хорошие результаты на одном компьютере и плохие результаты на другом, используя тот же инструмент, было бы неплохо выполнить некоторые тесты памяти на компьютере разработчика. Загрузочные образы для memtest86 могут быть легко получены, и некоторые ошибки памяти могут четко объяснить вашу проблему.
С другой стороны, если вы используете разные операционные системы на каждой машине, также возможно (возможно, даже более вероятно), что ошибка существует в версиях Windows любых кроссплатформенных библиотек, которые вы используете.