Mapped memory regions used by process

[GoogleCodeExporter]

This might be a nice addition, see:
http://stackoverflow.com/questions/2184775/getting-a-list-of-used-libraries-by-a
-running-process-unix

The way I see it, Process class should grow a new get_shared_libs() method 
returning a list of namedtuples including:

- absolute library path (e.g. /lib/x86_64-linux-gnu/libexpat.so.1)
- address (e.g. 00007f9babf44000)
- mode (e.g. "rw---" or the numeric representation)
- rss (memory resident set size)

Also, if the new method is invoked as such:

>>> get_shared_libs(extended=True)

...we can provide some extra platform-dependent fields such as pss/swap/... 
memory, inode, device no, etc (see "pmap -x PID" output on Linux and "man 
proc", sections /proc/[pid]/maps and /proc/[pid]/smaps).

For the Windows implementation we can look here: 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682621(v=vs.85).aspx
Judging from process hacker it seems we can retrieve all the fields listed 
above except "mode".

For BSD / OSX see "man pmap" as they seem the right sys-calls for doing this 
kind of job.

Original issue reported on code.google.com by g.rodola on 21 Apr 2012 at 7:59

[GoogleCodeExporter]

Do you also want WOW64 DLLs on 64-bit Windows systems?

Original comment by wj32...@gmail.com on 23 Apr 2012 at 11:59

[GoogleCodeExporter]

I suppose it makes sense, yes, unless it adds too much complexity.

Original comment by g.rodola on 23 Apr 2012 at 12:02

[GoogleCodeExporter]

Preliminary Linux patch in attachment.

Original comment by g.rodola on 23 Apr 2012 at 5:49

Attachments:

• linux-sharedlibs.patch

[GoogleCodeExporter]

What's the point of the "mode" field? Different sections of a mapped image are 
going to have different protection bits set.

Original comment by wj32...@gmail.com on 23 Apr 2012 at 10:54

[GoogleCodeExporter]

Completely untested patch.

Original comment by wj32...@gmail.com on 24 Apr 2012 at 10:58

Attachments:

• modules.patch

[GoogleCodeExporter]

On second thought I think we better off calling this function 
"get_memory_mappings()" since the stuff we're extracting is not related to 
shared libraries only.
On Linux, for example, we have "heap" and "anonymous" maps, which refer to 
application private data, same thing for other OSes, including Windows.
By taking a look at process hacker it seems that process "memory" tab is 
exactly what we're looking for (it also shows what looks like a "mode" column).

wj32.64, thanks for your patch; do you think you can adapt it in order to 
include also non-shared-lib mappings?
In process hacker I see "Private", "Mapped", "Free" and other stuff. That's 
what we're looking for and should be placed in "path" field.
Does that come from MODULEENTRY32 struct? If so I can adapt the patch myself.

Thanks in advance.

Original comment by g.rodola on 25 Apr 2012 at 1:58

[GoogleCodeExporter]

Sorry, I misunderstood the purpose of this feature, seeing as it's called 
"Shared libraries". It's easy to query all memory mappings in an address space, 
but it takes a lot more effort to get a list of heaps, stacks, etc.

Original comment by wj32...@gmail.com on 25 Apr 2012 at 2:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Sorry, I misunderstood the purpose of this feature,

It's my fault as at first I wasn't clear on the technical details involved.

> It's easy to query all memory mappings in an address space

Can you provide some more info? Is your patch still a valid starting point?

> it takes a lot more effort to get a list of heaps, stacks, etc.

Nevermind, I can live with that. 
The main reason why this is needed is to provide a more detailed process memory 
usage on Linux, as explained here:
http://bmaurer.blogspot.it/2006/03/memory-usage-with-smaps.html
Maybe that doesn't apply to Windows.

Original comment by g.rodola on 25 Apr 2012 at 3:33

[GoogleCodeExporter]

I'll need to rewrite the patch. It's a completely different API to query memory 
regions.

Original comment by wj32...@gmail.com on 25 Apr 2012 at 3:56