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 12/05/2011 2:48 PM, Corinna Vinschen wrote:
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 1:11 PM, Corinna Vinschen wrote:
On May 12 18:55, Corinna Vinschen wrote:
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
-    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
No, we need it.  The heaps consist of reserved and committed memory
blocks, as well as of shareable and non-shareable blocks.  Thus you
get multiple VirtualQuery calls per heap, thus you have to check for
the address within the entire heap(*).
Btw., here's a good example.  There are three default heaps, One of them,
heap 0, is the heap you get with GetProcessHeap ().  I don't know the
task of heap 1 yet, but heap 2 is ... something, as well as the stack of
the first thread in the process.  It looks like this:

   base 0x00020000, flags 0x00008000, granularity     8, unknown     0
   allocated     1448, committed    65536, block count 3
   Block 0: addr 0x00020000, size  2150400, flags 0x00000002, unknown 0x00010000

However, the various calls to VirtualQuery result in this output with
my patch:

   00020000-00030000 rw-p 00000000 0000:0000 0      [heap 2 default share]
   00030000-00212000 ---p 00000000 0000:0000 0      [heap 2 default]
   00212000-00213000 rw-s 001E2000 0000:0000 0      [heap 2 default]
   00213000-00230000 rw-p 001E3000 0000:0000 0      [heap 2 default]

The "something" is the sharable area from 0x20000 up to 0x30000.  The
stack is from 0x30000 up to 0x230000.  The first reagion is only
reserved, then the guard page, then the committed and used  tack area.
Hmm. It looks like heap 2 was allocated by mapping the pagefile
rather than using VirtualAlloc, and the thread's stack was allocated
from heap 2, which treated the request as a large block and returned
the result of a call to VirtualAlloc.

Are the other two heap bases not "default share" then?
Here's what I see for instance in tcsh:

00010000-00020000 rw-p 00000000 0000:0000 0 [heap 1 default share]

00020000-00030000 rw-p 00000000 0000:0000 0       [heap 2 default share]
00030000-00212000 ---p 00000000 0000:0000 0       [heap 2 default]
00212000-00213000 rw-s 001E2000 0000:0000 0       [heap 2 default]
00213000-00230000 rw-p 001E3000 0000:0000 0       [heap 2 default]

002E0000-00310000 rw-p 00000000 0000:0000 0       [heap 0 default grow]
00310000-003E0000 ---p 00030000 0000:0000 0       [heap 0 default grow]

In any case, coming back to the allocation base issue, heap_info
only needs to track 0x20000 and 0x30000, because they are the ones
with offset zero that would trigger a call to
heap_info::fill_on_match. I argue that heap walking found exactly
two flags&2 blocks, with exactly those base addresses, making the
range check in fill_on_match unecessary.
Nope.  As I wrote in my previoous mail and as you can still see in my
quote above, the two virtual memory areas from 0x20000 to 0x30000 and
from 0x30000 to 0x230000 together constitute a single start block in
heap 2.  The OS is a great faker in terms of information returned to
the application, apparently.
OK. I finally understand now. I was assuming the heap would not report multiple allocations as a single heap region.

Windows is weird.

Ryan


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