как использовать память трека windbg, выделенную с помощью VirtualAlloc?

Question

вы знаете, как вы можете использовать gflags wih + ust для соединения стека вызовов с каждым распределением.затем вы можете использовать! heap в windbg для диагностики утечек?

Я хочу сделать это с большими выделениями, сделанными через VirtualAlloc.Насколько я могу судить, VirtualAlloc обходит расширения кучи gflags /!?

Я надеюсь, что кто-то может подтвердить

a)! Heap просматривает список выделенной памяти в каждой куче, но невыделенная память, полученная из VirtualAlloc

b) при выделении огромного куска памяти через new / malloc, который идет в LocalAlloc () и затем в VirtualAlloc (), где он обходит протоколирование стека вызовов

Я действительно надеюсь, что кто-то может помочь мне в устранении такой утечки.если бы распределение было меньше, у меня не было бы проблем! heap

Answer 1

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

Answer 2

Фон

Операционная система предоставляет память только через VirtualAlloc ().Это работает хорошо, но детализация не очень хорошая: она может обеспечить только 64 КБ одновременно.Вот почему Microsoft внедрила разные менеджеры кучи, например, менеджер кучи C ++ или менеджер кучи .NET.Они получают память из ОС в блоках по 64 КБ и предоставляют ее программам на C ++ или .NET небольшими порциями.

!heap и связанные команды работают только для менеджера кучи C ++.Для проверки кучи .NET вам нужно расширение sos для WinDbg.

Что касается ваших вопросов

Насколько я могу судить, VirtualAlloc обходит gflags /! heap extensions?

Флаг GFlags +ust относится к выделению кучи в C ++.Команды !heap также относятся к диспетчеру кучи C ++, поэтому да, ни одна из них не будет заботиться о вызовах VirtualAlloc ().

Однако я бы не сказал, что VirtualAlloc () «обходит» их, что будет утверждением, что он проходит через менеджер кучи C ++.Скорее наоборот: он находится на более низком уровне, чем работает менеджер кучи.

a)! Heap просматривает список выделенной памяти в каждой куче, но не выделенную память, полученную из VirtualAlloc

Да, по той же причине.

b) когда вы выделяете огромный кусок памяти через new / malloc, который идет в LocalAlloc (), а затем в VirtualAlloc (), гдеон обходит протоколирование стека вызовов

В основном да.Есть момент, когда больше не стоит разбивать память на более мелкие регионы.Очевидно, что выделение 64 КБ для 2-байтовой переменной - это слишком много.

Microsoft подвела черту на ~ 512 КБ, как описано в HeapAlloc (ищите термин 0x7FFF8).Поэтому, когда вы выделяете более 512 КБ, он больше не будет использовать диспетчер кучи, кроме необработанного блока памяти VirtualAlloc ().В худшем случае накладные расходы составляют 12% (трата 64 КБ при выделении 512 КБ + 1 байт).

Не волнуйтесь

Существуют другие инструменты для распознавания больших утечек памяти, которые возникаютот VirtualAlloc ().Команда WinDbg !address полезна, а Rohitab API monitor может помочь.Как советуют другие, вы также можете попробовать LeakDiag или коммерческие анализаторы утечек памяти.

Answer 3

Функции кучи работают на более высоком уровне, чем функции Virtual*;фактически, куча должна вызывать VirtualAlloc, чтобы добавить больше памяти в адресное пространство процесса.!heap не собирается помогать вам с Virtual* звонками.