Как получить доступ к полной трассировке стека mallocs в приложении MFC 8.0?

Question

Я пытаюсь найти утечку памяти в приложении Windows MFC 8.0 (Release build).

После неудачной попытки показать полные трассировки стеки распределений с использованием WinDbg (или UMDH) из-за VC8 CRT's malloc problem with FPO, я попытался применить предложенное решение here (т.е. с использованием LeakDiag с DbgHlp StackWalk включен), только чтобы понять, что делает LeakDiag НЕ генерировать файл журнала при мониторинге C Runtime Allocator, однако при мониторинге Windows Heap Allocator он действительно работает, но опять же трассировка стека заканчивается при вызове malloc.

Символы настроены правильно, так как я могу видеть имена функций, имена файлов, строки и т. Д. В сгенерированном файле.

Кто-нибудь знает, почему я не могу зарегистрировать C Runtime Allocator? и почему я не могу получить полную трассировку стека, даже если я использую API-интерфейс DbgHlp StackWalk?

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

Дополнительная информация:

Как мой стек следы выглядеть следующим образом:

У меня это с помощью WinDbg. Адрес - это один из сообщений heap -l как просочившийся блок.

0:000> !heap -p -a 25b18400 
address 25b18400 found in 
_HEAP @ 2a70000 
    HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 
    25b183f8 0008 0000 [07] 25b18400 00021 - (busy) 
    Trace: 00a4 
    7c97d6dc ntdll!RtlDebugAllocateHeap+0x000000e1 
    7c959d18 ntdll!RtlAllocateHeapSlowly+0x00000044 
    7c92b298 ntdll!RtlAllocateHeap+0x00000e64 
    78134d83 MSVCR80!malloc+0x0000007a 

Answer 1

Почему вы не используете сторонние инструменты?

I.e. загрузить оценочную копию параллельного инспектора Intel. Его довольно просто установить и запустить против существующей сборки релиза. И он показывает - в большинстве случаев - полный стек (я уверен, хотя он также находит некоторые ложные срабатывания).

Выберите версию выпуска из диспетчера конфигурации и убедитесь, что она создает файл pdb (в вариантах компоновщика). Затем просто запустите «Осмотреть ошибки памяти».

Существует множество других сопоставимых инструментов: AQTime, GlowCode. Все это не требует перекомпиляции или инструментария.

Answer 2

Кто-нибудь знает, почему я не могу войти в C времени выполнения Allocator?

Вы используете сборку отладки? У Debug CRT есть своя собственная проверка кучи, которая побеждает UMDH и другие инструменты, которые работают с глобальной кучей ОС. Убедитесь, что все функции отладки кучи MFC и MSVCRT: выключены при использовании UMDH и друзей.

Возможно, и вы, или что-то в вашем процессе, changed the small-block allocator threshold от значения по умолчанию 0.

противном случае, 8,0 релиз CRT должен просто переслать запрос в глобальной куче, которая является то, что вы хотите для отладки кучи инструментов.

и почему я не могу получить полную трассировку стека, даже если я использую API-интерфейс DbgHlp StackWalk?

Я думаю, что Skywing подробно описал детали в ссылках, которые вы дали. Для повторной итерации часть, которую он, возможно, немного заявила, «на x86,« идеальные »трассировки стека вообще не возможны, поскольку нет метаданных, прикрепленных к определенной функции (вне символов отладки), которая описывает, как расслабьтесь от него ». Для DbgHlp совсем нецелесообразно отключать функцию (например, malloc MSVCRT) с использованием EBP в качестве регистра нуля.

Возможно, вы можете восстановить свою собственную CRT-библиотеку из исправленных источников или попытаться заменить CRT malloc/free.

Действительно, я думаю, что ваш лучший способ - воспроизвести утечку на платформе x64, где бесперебойное стекирование гарантировано будет достаточно надежным.