Я хотел бы проверить родную кучу процесса, чтобы увидеть, какие нативные классы присутствуют в памяти и каков их размер. Это эквивалентно команде sos! Dumpheap -stat. Возможно ли это сделать на родной стороне?
Я предполагаю, что причина, по которой вы хотите проверить собственную кучу, состоит в том, чтобы проанализировать использование кучи и, возможно, выяснить, какова структура выделений в куче и какая часть кода отвечает за это. Если это так, выход из UMDH инструмент — самый близкий, о котором я могу думать. Это гораздо более многословно, чем !dumpheap -stat
, но вы можете получить гораздо больше от этого — например, Вы можете точно определить точный код, который отвечает за распределение, просмотрев стеки вызовов распределения.
Обычно Umdh используется для диагностики утечек памяти. Чтобы получить разбивку всех выделений в процессе, вам нужно будет использовать так называемый режим единого дампа.
Хотя вывод Umdh не скажет вам напрямую, какой тип выделен, в большинстве случаев вы можете легко вывести его из стека вызовов распределения. Например, в этом фрагменте из вывода Umdh есть распределения 0x4a, потребляющие всего 0x194b0 байтов, и тип распределения легко определить, так как std::vector<unsinged short>
находятся в стеке вызовов, и распределение было выполнено в методе RecordData :: Deserialize.
+ 194b0 ( 194b0 - 0) 4a allocs BackTraceD0F18F8 + 4a ( 4a - 0) BackTraceD0F18F8 allocationsntdll!RtlAllocateHeap+36991 MSVCR120D!_heap_alloc_base+51 (f:\dd\vctools\crt\crtw32\heap\malloc.c, 58) MSVCR120D!_heap_alloc_dbg_impl+1FF (f:\dd\vctools\crt\crtw32\misc\dbgheap.c, 431) MSVCR120D!_nh_malloc_dbg_impl+1D (f:\dd\vctools\crt\crtw32\misc\dbgheap.c, 239) MSVCR120D!_nh_malloc_dbg+2A (f:\dd\vctools\crt\crtw32\misc\dbgheap.c, 302) MSVCR120D!malloc+19 (f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c, 56) MSVCR120D!operator new+F (f:\dd\vctools\crt\crtw32\heap\new.cpp, 59) STestViewer!std::_Allocate<unsigned short>+2F (c:\program files (x86)\microsoft visual studio 12.0\vc\include\xmemory0, 28) STestViewer!std::allocator<unsigned short>::allocate+19 (c:\program files (x86)\microsoft visual studio 12.0\vc\include\xmemory0, 578) STestViewer!std::_Wrap_alloc<std::allocator<unsigned short> >::allocate+1A (c:\program files (x86)\microsoft visual studio 12.0\vc\include\xmemory0, 848) STestViewer!std::vector<unsigned short,std::allocator<unsigned short> >::_Reallocate+57 (c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector, 1588) STestViewer!std::vector<unsigned short,std::allocator<unsigned short> >::_Reserve+5A (c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector, 1619) TestViewer!std::vector<unsigned short,std::allocator<unsigned short> >::resize+FC (c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector, 1136) TestViewer!RecordData::Deserialize+52 (c:\src\stcommonlib\stdmodel.cpp, 174) TestViewer!SensorDrModel::LoadFromFile+21E (c:\src\stcommonlib\stsmodel.cpp, 50)
[/ NOEDIT]
В других случаях тип объекта не очевиден из стека вызовов, но так как у вас есть имя исходного файла и номер строки, что вызвало
operator new
Вы можете установить это, посмотрев на исходный код.к суммировать что вы получаете с Umdh:
- Это не прямой аналог! dumpheap.
- Вы будете проводить с этим гораздо больше времени, потому что это очень многословно.
- Однако вы можете извлечь информацию о причине, по которой распределение произошло в первую очередь, чего вы не можете сделать из! Dumpheap.
Краткий ответ: нет. Вы можете просмотреть кучу и увидеть размеры распределенных блоков, но один из основных фактов жизни нативного кода заключается в том, что вы не можете зависеть от него, чтобы помещать теги типа в выделенные объекты, поэтому объект в куче обычно не содержит достаточно информации, чтобы выяснить его тип.
Когда вы имеете дело с чем-то вроде кучи Windows GDI (которая помещает теги типа в выделенные объекты), вы можете сделать это, но для другого кода, который просто выделяет и использует память, необходимой вам информации просто не существует.
Я, вероятно, должен добавить: если у вас есть отладочная информация (и мало заботитесь о скорости выполнения), возможно, можно отследить выделения и типы, которым они назначены, так что вы сможете работать в обратном направлении от выделенных кусков памяти до фактического типы объектов. Некоторые инструменты для отладки кучи сделали что-то похожее на это, хотя я не знаю ни одного, что делает именно то, что вы просите.