Программное обеспечение для отслеживания нескольких ошибок памяти в старом проекте?

Question

Я программирую игру 2 года назад. иногда некоторые ошибки памяти (то есть: функция, возвращающая ненужную информацию вместо того, что она должна была вернуть, или сбой, который происходит только в Linux и никогда не происходит в GDB или Windows), происходят случайно. То есть я пытаюсь это исправить, и спустя несколько месяцев те же ошибки возвращаются, чтобы преследовать меня.

Есть программное обеспечение (не Valgrind, я уже пробовал ... оно не находит ошибок), которое может помочь мне с этой проблемой? Или способ решения этих ошибок? Я хочу исправить их навсегда.

Answer 1

В Windows вы можете автоматически перехватить аварийное исключение в производственной среде и проанализировать его, как если бы ошибка произошла на вашем компьютере разработчика под отладчиком. Это делается с помощью файла "мини-дамп". Вы в основном используете Windows «dbghelp.dll» DLL для создания копии стеков потоков, частей или всей кучи, значений регистров, загруженных модулей и необработанного исключения, которое привело к сбою. Вы можете запустить этот файл ".dmp" в отладчике MS Visual Studio, как если бы он был исполняемым файлом, и он точно покажет вам, где произошел сбой.

Вы можете установить ловушку для необработанных исключений и делегировать создание файла мини-дампа dbghelp.dll в этой ловушке. Вам необходимо сохранить файлы «.pdb», которые были сгенерированы с развернутыми двоичными файлами, чтобы сопоставить адреса памяти с расположениями исходного кода для лучшего процесса отладки. Эта тема слишком глубока, чтобы полностью охватить ее. См. документацию Microsoft для этой DLL.

Вам необходимо иметь возможность скопировать файл .dmp с ПК, на котором он произошел сбой, в вашу среду разработки, чтобы полностью отладить его. Если у вас сложились отношения с вашими пользователями, вам нужно иметь возможность иметь отдельное служебное приложение «Телефон дома» через Интернет для передачи файла .dmp в место, где вы можете получить к нему доступ. Вы можете запустить приложение из ловушки необработанного исключения после того, как файл .dmp был сгенерирован. Для обеспечения конфиденциальности пользователя вы должны предоставить пользователю возможность делать это или нет.

Answer 2

Одна вещь, которую вы можете попробовать, - это использовать Ганс Бем ГХ в вашем проекте. Его можно использовать как детектор утечек, что позволяет вам удалять подозрительно выглядящие операторы free() или delete и легко видеть, вызывают ли они утечки памяти.

Answer 3

Отладчик Totalview (коммерческое программное обеспечение) может обнаружить сбой.

Purify (коммерческое программное обеспечение) может помочь вам найти утечки памяти.

Ваш код компилируется без предупреждений компилятора? Ты бежал ворсом?

Answer 4

Чтобы избежать этого в моих собственных проектах (в Windows), я написал свой собственный распределитель памяти, который просто назывался VirtualAlloc и VirtualFree. Он выделил дополнительную страницу для каждого запроса, выровнял ее по левому краю последней страницы и использовал VirtualProtect для генерации исключения при каждом доступе к последней странице. Это обнаружило за пределами доступа, даже просто читает, на месте.

Отказ от ответственности: я ни в коем случае не был первым, кто получил эту идею.

Например, если страницы имеют размер 4096 байт и был вызван new int[1], распределитель будет:

1. Выделите 8192 байта (необходимо 4 байта, что составляет одну страницу, а дополнительная страница защиты приносит общее количество до 2 страниц)
2. Отметить последнюю страницу как недоступную
3. Определить адрес для возврата (последняя выделенная страница начинается с 4096 ... 4096 - 2 = 4092)

Следующий код:

main() {
    int *array = new int[10];
    return array[10];
}

будет генерировать нарушение доступа на месте.

У него также была опция (время компиляции) для обнаружения обращений за пределами левой стороны выделения (т. Е. Массива [-1]), но ошибки такого рода казались редкими, поэтому я использовал опцию.

Answer 5

AFAIK, Boundscheck в Windows делает очень хорошую работу. В одном из моих проектов он обнаружил несколько очень странных ошибок.