эквивалент! dumpheap -stat на нативной стороне

Я хотел бы проверить родную кучу процесса, чтобы увидеть, какие нативные классы присутствуют в памяти и каков их размер. Это эквивалентно команде sos! Dumpheap -stat. Возможно ли это сделать на родной стороне?

2

Решение

Я предполагаю, что причина, по которой вы хотите проверить собственную кучу, состоит в том, чтобы проанализировать использование кучи и, возможно, выяснить, какова структура выделений в куче и какая часть кода отвечает за это. Если это так, выход из UMDH инструмент — самый близкий, о котором я могу думать. Это гораздо более многословно, чем !dumpheap -stat, но вы можете получить гораздо больше от этого — например, Вы можете точно определить точный код, который отвечает за распределение, просмотрев стеки вызовов распределения.

Обычно Umdh используется для диагностики утечек памяти. Чтобы получить разбивку всех выделений в процессе, вам нужно будет использовать так называемый режим единого дампа.

Хотя вывод Umdh не скажет вам напрямую, какой тип выделен, в большинстве случаев вы можете легко вывести его из стека вызовов распределения. Например, в этом фрагменте из вывода Umdh есть распределения 0x4a, потребляющие всего 0x194b0 байтов, и тип распределения легко определить, так как std::vector<unsinged short> находятся в стеке вызовов, и распределение было выполнено в методе RecordData :: Deserialize.

+   194b0 ( 194b0 -     0)     4a allocs    BackTraceD0F18F8
+      4a (    4a -     0)  BackTraceD0F18F8    allocations

ntdll!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:

  1. Это не прямой аналог! dumpheap.
  2. Вы будете проводить с этим гораздо больше времени, потому что это очень многословно.
  3. Однако вы можете извлечь информацию о причине, по которой распределение произошло в первую очередь, чего вы не можете сделать из! Dumpheap.
3

Другие решения

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

Когда вы имеете дело с чем-то вроде кучи Windows GDI (которая помещает теги типа в выделенные объекты), вы можете сделать это, но для другого кода, который просто выделяет и использует память, необходимой вам информации просто не существует.

Я, вероятно, должен добавить: если у вас есть отладочная информация (и мало заботитесь о скорости выполнения), возможно, можно отследить выделения и типы, которым они назначены, так что вы сможете работать в обратном направлении от выделенных кусков памяти до фактического типы объектов. Некоторые инструменты для отладки кучи сделали что-то похожее на это, хотя я не знаю ни одного, что делает именно то, что вы просите.

5

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector