On May 12 15:30, Ryan Johnson wrote:
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
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
Hi Ryan,
On May 11 01:27, Ryan Johnson wrote:
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
Thanks!
I applied youyr two first patches with a couple of changes:
- Formatting: Setting of curly braces in class and method defintions,
a lot of
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
On 11/05/2011 6:31 AM, Corinna Vinschen wrote:
Hi Ryan,
On May 11 01:27, Ryan Johnson wrote:
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
Thanks!
I applied youyr two first patches with a couple of changes:
- Formatting: Setting of curly braces
On 11/05/2011 9:20 AM, Corinna Vinschen wrote:
On May 11 08:53, Ryan Johnson wrote:
On 11/05/2011 6:31 AM, Corinna Vinschen wrote:
- I replaced the call to GetMappedFileNameEx with a call to
NtQueryVirtualMemory (MemorySectionName). This avoids to add another
dependency to psapi. I
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
On May 11 13:46, Ryan Johnson wrote:
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
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
The first (proc-maps-files) makes format_process_maps report all
reserved or committed address space, rather than just the parts occupied
by dlls in the dll_list. It splits allocations when they have
23 matches
Mail list logo