This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extending /proc/*/maps


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]