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.
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 un
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 bloc
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 ori
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
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
#define _WIN32_WINNT 0x0601
#include
#include
#include
typedef struct _MODULES
{
ULONG coun
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 ba
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
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
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 c
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 n
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 s
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
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 of
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 bloc
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 th
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
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
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 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 inte
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 intend to get rid of them entirely, if
> >
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 i
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 fetc
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
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 m
25 matches
Mail list logo
