Extending /proc/*/maps

[Ryan Johnson]

On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
> On May 12 14:10, Corinna Vinschen wrote:
>> On May 11 21:31, Corinna Vinschen wrote:
>>> On May 11 13:46, Ryan Johnson wrote:
>>>> 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.
>>> While the base address of the heap is available in
>>> DEBUG_HEAP_INFORMATION, I don't see the size of the heap.  Maybe it's in
>>> the block of 7 ULONGs marked as "Reserved"?  It must be somewhere.
>>> Assuming just that, you could scan the list of blocks once and drop
>>> those within the orignal heap allocation.  The remaining blocks are big
>>> blocks which have been allocated by additional calls to VirtualAlloc.
>> After some debugging, I now have the solution. [...]
> Here's a prelimiary patch to fhandler_process.cc which takes everything
> into account I have learned in the meantime.  For instance, there are
> actually heaps marked as shareable.  Please have a look.  What's missing
> is the flag for low-fragmentation heaps, but I'm just hunting for it.
I like it. Detailed comments below.

> +/* Known heap flags */
> +#define HEAP_FLAG_NOSERIALIZE	0x1
> +#define HEAP_FLAG_GROWABLE	0x2
> +#define HEAP_FLAG_EXCEPTIONS	0x4
> +#define HEAP_FLAG_NONDEFAULT	0x1000
> +#define HEAP_FLAG_SHAREABLE	0x8000
> +#define HEAP_FLAG_EXECUTABLE	0x40000
Would it make sense to put those in ntdll.h along with the heap structs 
that use them?

>     struct heap
>     {
>       heap *next;
> -    void *base;
> +    unsigned heap_id;
> +    uintptr_t base;
> +    uintptr_t end;
> +    unsigned long flags;
>     };
We don't actually need the end pointer: we're trying to match an unknown 
allocation base against heap region bases. The code which traverses VM 
allocations should query heap_info at most once per allocation (for 
example, it only looks up the file name of cygwin1.dll once even though 
the latter has 12 entries in /proc/*/maps).

>     heap *heaps;
This is a misnomer now -- it's really a list of heap regions/blocks.

> +		heap *h = (heap *) cmalloc (HEAP_FHANDLER, sizeof (heap));
> +		*h = (heap) {heaps, hcnt, barray[bcnt].Address,
> +			     barray[bcnt].Address + barray[bcnt].Size,
> +			     harray->Heaps[hcnt].Flags};
> +		heaps = h;
Given that the number of heap blocks is potentially large, I think it 
makes sense to build a sorted list. That way, each query examines only 
one heap block (deleting it unless it was above the queried address). I 
have ready-but-unsent a patch which does this to the checked-in version 
of the code. Shall I send it?

> -  char *fill_if_match (void *base, char *dest )
> +  char *fill_if_match (void *base, ULONG type, char *dest )
>     {
> -    long count = 0;
> -    for (heap *h = heaps; h&&  ++count; h = h->next)
> -      if (base == h->base)
> +    for (heap *h = heaps; h; h = h->next)
> +      if ((uintptr_t) base>= h->base&&  (uintptr_t) base<  h->end)
>   	{
> -	  __small_sprintf (dest, "[heap %ld]", count);
> +	  char *p;
> +	  __small_sprintf (dest, "[heap %ld", h->heap_id);
> +	  p = strchr (dest, '\0');
> +	  if (!(h->flags&  HEAP_FLAG_NONDEFAULT))
> +	    p = stpcpy (p, " default");
> +	  if ((h->flags&  HEAP_FLAG_SHAREABLE)&&  (type&  MEM_MAPPED))
> +	    p = stpcpy (p, " share");
> +	  if (h->flags&  HEAP_FLAG_EXECUTABLE)
> +	    p = stpcpy (p, " exec");
> +	  if (h->flags&  HEAP_FLAG_GROWABLE)
> +	    p = stpcpy (p, " grow");
> +	  if (h->flags&  HEAP_FLAG_NOSERIALIZE)
> +	    p = stpcpy (p, " noserial");
> +	  stpcpy (p, "]");
>   	  return dest;
>   	}
>       return 0;
Do you actually encounter requests which fall inside a heap region 
rather than at its start? I have not seen this in my experiments, and if 
you have it is almost certainly a bug in format_process_maps' allocation 
traversal.

Also, are there ever shareable-but-not-mem_mapped segments? If not, we 
could probably remove 'type.'

Ryan