Обнаружение утечки памяти во время выполнения модульных тестов

Question

У меня есть приложение Win32 C++ с набором модульных тестов. После того, как модульные тесты закончатся, я хотел бы, чтобы автоматически создавался отчет, который можно было бы читать по любой свободной памяти. В идеале, в отчете будет стек с файлами & информация о номере линии для каждого разрозненного выделения. Было бы неплохо, если бы они были сгенерированы в последовательном порядке, чтобы было проще разграничить их от одного прохода к следующему. (В принципе, мне бы хотелось, чтобы результаты valgrind --leak-check = full, но на окнах).

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

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

Спасибо!

Answer 1

Я играл с функциями CRT Debug Heap Mike B указал, но в конце концов я не был удовлетворен просто получить адрес просочилась памяти. Получение стеков, таких как UMDH, делает отладку намного быстрее. Итак, теперь в моей функции main() я запускаю UMDH с помощью CreateProcess до и после запуска тестов для получения снимков кучи.Я также написал тривиальный командный файл, который запускает мой тестовый жгут, а затем разворачивает снимки кучи. Итак, я запускаю командный файл и получаю результаты своих тестов и текстовый файл с полными стеками любых несанкционированных распределений всего за один выстрел.

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

Теперь, если я только что способ обнаружить, если я не закрывал никаких ручек ...

Answer 2

Если вы используете MSVC, функции кучи отладки Microsoft можно использовать для создания отчета вы хотите, но это не может быть столь же автоматически, как вы хотите (вы, возможно, придется написать собственный код):

Answer 3

Для получения такого рода информации мы переопределяем новые/delete и malloc/free, предоставляя наши собственные реализации кучи, которые хранят стек стежков при распределении и создают отчет, когда куча уничтожается (а также добавление стражей для обнаружения буфера перерасход).

Это прекрасная работа в первый раз, когда вы это делаете. This guy написал бесплатный инструмент, который обрабатывает все жесткие бит - я сам не пробовал, но его объяснение того, как он это написал, полезно, когда вы катаетесь самостоятельно.

Answer 4

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

Смотреть подробнее здесь:

http://msdn.microsoft.com/en-us/library/tz7sxz99(VS.80).aspx

Answer 5

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

Я использовал debug functions, о котором упомянул Майк Б (кстати, они работают только в Debug).

Тест-драйв прошел все тесты дважды, потому что во время первого запуска память выделяется для глобальных переменных. Во второй раз общее количество выделенных блоков было проверено до и после каждого теста (я думаю, вы можете сделать это в setUp() и tearDown()). Если число было другим, это означало утечку памяти, и тест не прошел с соответствующим сообщением. Конечно, если сам тест терпит неудачу, вы должны сохранить его сообщение об ошибке. Теперь, чтобы найти утечку, мне пришлось прочитать номер выделения блока последнего распределения с помощью pBlockHeader, затем установить точку останова на нем с помощью _CrtSetBreakAlloc и запустить снова.

Подробнее об этом здесь: http://levsblog.wordpress.com/2008/10/31/unit-testing-memory-leaks/