best way to discover this process's current memory usage, cross-platform?
Jack Diederich
jack at performancedrivers.com
Wed Nov 16 10:34:19 EST 2005
On Tue, Nov 15, 2005 at 10:10:42PM -0800, Neal Norwitz wrote:
> Alex Martelli wrote:
> > matt <matthewharrison at gmail.com> wrote:
> >
> > > Perhaps you could extend Valgrind (http://www.valgrind.org) so it works
> > > with python C extensions? (x86 only)
> >
> > Alas, if it's x86 only I won't even look into the task (which does sound
> > quite daunting as the way to solve the apparently-elementary question
> > "how much virtual memory is this process using right now?"...!), since I
> > definitely cannot drop support for all PPC-based Macs (nor would I WANT
> > to, since they're my favourite platform anyway).
>
> Valgrind actually runs on PPC (32 only?) and amd64, but I don't think
> that's the way to go for this problem.
>
> Here's a really screwy thought that I think should be portable to all
> Unixes which have dynamic linking. LD_PRELOAD.
>
> You can create your own version of malloc (and friends) and free. You
> intercept each call to malloc and free (by making use of LD_PRELOAD),
> keep track of the info (pointers and size) and pass the call along to
> the real malloc/free. You then have all information you should need.
> It increases the scope of the problem, but I think it makes it soluble
> and somewhat cross-platform. Using LD_PRELOAD, requires the app be
> dynamically linked which shouldn't be too big of a deal. If you are
> using C++, you can hook into new/delete directly.
>
Electric Fence[1] uses the LD_PRELOAD method. I've successfully used it to
track down leaks in a python C extension. If you look at the setup.py in
probstat[2] you'll see
#libraries = ["efence"] # uncomment to use ElectricFence
which is a holdover from developing.
-Jack
[1] http://perens.com/FreeSoftware/ElectricFence/
[2] http://probstat.sourceforge.net/
More information about the Python-list
mailing list