On May 11 22:58, Yaakov (Cygwin/X) wrote:
On Mon, 2011-05-09 at 09:55 +0200, Corinna Vinschen wrote:
I'm not sure I understand this new format. Why do you keep the Mem: and
Swap: lines? Linux doesn't have them and top appears to work without
them. And then, why do you print MemShared,
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
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
On 11/05/2011 3:31 PM, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
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
On May 12 12:31, Ryan Johnson wrote:
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
On May 12 12:37, Ryan Johnson wrote:
On 11/05/2011 3:31 PM, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
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
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:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
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
No, we need it. The heaps
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
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
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
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;
On May 12 20:42, Corinna Vinschen wrote:
I created a test application with several heaps [...]
Btw., here's my test app. It's ugly but it's just for testing the
results anyway.
Corinna
#include stdio.h
#define _WIN32_WINNT 0x0601
#include windows.h
#include ddk/ntddk.h
#include ddk/ntapi.h
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
On 12/05/2011 2:42 PM, Corinna Vinschen wrote:
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
heap *heaps;
This is a misnomer now -- it's really a list of heap regions/blocks.
I don't think so. The loop stores only the blocks which constitute
the
On May 12 15:19, Ryan Johnson wrote:
On 12/05/2011 2:48 PM, Corinna Vinschen wrote:
Nope. As I wrote in my previoous mail and as you can still see in my
quote above, the two virtual memory areas from 0x2 to 0x3 and
from 0x3 to 0x23 together constitute a single start block in
On May 12 20:42, Corinna Vinschen wrote:
As for the big blocks, they are apparently identified by the value in
the Unknown member of the DEBUG_HEAP_BLOCK structure. Here's what I
figured out so far as far as Unknown is concerned:
Scratch that. I finally *really* figured out what the unknown
16 matches
Mail list logo
