Extending /proc/*/maps

[Ryan Johnson]

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