Как отслеживать утечки памяти с помощью umdh.exe во всех кучах?

Question

У меня есть приложение C++ windows, которое утечки памяти за транзакцию. Используя perfmon, я могу видеть увеличение личных байтов с каждой транзакцией, использование памяти является плоской, пока приложение не работает.

После предыдущих ответов на stackoverflow я использовал umdh из средств отладки microsoft для отслеживания утечки памяти. Однако есть еще больше утечек, и результаты umdh не соответствуют моим результатам.

Первый UMDH ли еще сообщает эту утечку, стек трассировки:

+ 36192 (2082056 - 2045864) 251 allocs BackTraceCB 
+  4 ( 251 - 247) BackTraceCB allocations 

    ntdll!RtlAllocateHeapSlowly+00000041 
    ntdll!RtlAllocateHeap+00000E9F 
    MSVCR80!malloc+0000007A 

Это не использовать как первый вызов таНос, он не говорит, что это называется. У меня есть сомнения относительно этой утечки, поскольку сообщается как при обработке заявки, так и при ее простаивании. Но я ясно вижу, что память не протекает, когда она простаивает. И утечка памяти, сообщаемая при обработке транзакций, не пропорциональна транзакциям, обрабатываемым как отчеты perfmon.

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

• Не может ли быть, что umhd сообщает только об использовании памяти из одной из этих кучей? например, по умолчанию или crt-кучу?
• Как я могу отслеживать использование памяти в других кучах?
• И как узнать, какие DLL/модули используют другие кучи?

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

Answer 1

Извините, что ответили на мой вопрос, но я, наконец, отследил проблему до того, как я использовал Orbix.

Это означает, что библиотеки orbix используют свою кучу на платформе Windows. Это означает, что большинство обнаружений утечки памяти не работает для утечек в orbix, я попробовал boundschecker и umhd.exe.

Чтобы изолировать этот вопрос я нашел некоторый код, который будет дамп памяти каждой кучи в приложении: http://www.abstraction.net/content/articles/analyzing%20the%20heaps%20of%20a%20win32%20process.htm

я использовал это, чтобы сбросить использование кучи до и после каждой операции, а затем через каждые 500 сделок, это что одна и та же куча росла каждый раз. Затем я перечислил адрес каждой записи в этой куче. Изучив память в этих областях, я обнаружил, что они содержат данные о сортировке орби-файлов. С этой информацией я наконец нашел некоторые ссылки на объекты, которые не были очищены.

Answer 2

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

Answer 3

Возможно, у umdh возникли проблемы с поиском отладочных символов для вашего кода? Это может объяснить, почему трассировка стека является неполной. Убедитесь, что вы создали его с символами и что их можно найти.

Answer 4

Я использую для просмотра кода в поисках утечек памяти.

Некоторые вещи, которые я искал: проблема

1. Наследование: базовые классы, которые не предоставляют виртуальный деструктор и используются полиморфно.
2. Поиск в коде деклараций указателей или указателей (поиск * объявлений или ключевое слово new или использование malloc), а также просмотр фрагментов кода, ориентированных на жизненный цикл динамически распределенных объектов.

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

Answer 5

Для меня, в случаях, когда umdh не удалось - другой MS бесплатный инструмент под названием LeakDiag преуспел. Это позволяет перехватывать гораздо больше типов распределителей, чем umdh, включая то, что он называет «распределителем MPHeap», который I suspect может быть вам полезен. Если у вас есть свободная минута - мне любопытно, может ли это действительно помогло ...