best way to discover this process's current memory usage, cross-platform?

Jack Diederich jack at performancedrivers.com
Wed Nov 16 16:34:19 CET 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