On 11/05/2011 7:14 AM, Corinna Vinschen wrote:
On May 11 01:27, Ryan Johnson wrote:
The second (proc-maps-heaps) adds reporting of Windows heaps (or
their bases, at least). Unfortunately there doesn't seem to be any
efficient way to identify all virtual allocations which a heap owns.
There's a call RtlQueryDebugInformation which can fetch detailed heap
information, and which is used by Heap32First/Heap32Last. Using it
directly is much more efficient than using the Heap32 functions. The
DEBUG_HEAP_INFORMATION is already in ntdll.h, what's missing is the
layout of the Blocks info. I found the info by googling:
typedef struct _HEAP_BLOCK
{
PVOID addr;
ULONG size;
ULONG flags;
ULONG unknown;
} HEAP_BLOCK, *PHEAP_BLOCK;
If this information is searched until the address falls into the just
inspected block of virtual memory, then we would have the information,
isn't it?
The problem is that the reported heap blocks corresponded to individual
malloc() calls when I tested it (unordered list, most sizes < 100B). I
really would have preferred a function that returns the list of memory
regions owned by the heap. They must track that information -- I highly
HeapDestroy uses these heap blocks to decide which memory regions to
VirtualFree, but that info seems to live in the kernel...
Given that Heap32* has already been reverse-engineered by others, the
main challenge would involve sorting the set of heap block addresses and
distilling them down to a set of allocation bases. We don't want to do
repeated linear searches over 50k+ heap blocks.
Also, the cygheap isn't a normal windows heap, is it? I thought it was
essentially a statically-allocated array (.cygheap) that gets managed as
a heap. I guess since it's part of cygwin1.dll we already do sort of
report it...
Ryan