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

[Alex Martelli]

sjdevnull at yahoo.com <sjdevnull at yahoo.com> wrote:
   ...
> Neal  Norwitz wrote:
> > 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.
> 
> That'll only get you memory usage from malloc/free calls, which could
> be vastly less than the process' memory usage in plausible scenarios
> (e.g. a media player that uses mmap() to read the file, or anything
> that uses large shared memory segments generated with mmap() or SysV
> IPC, etc).

True.  But hopefully a cross-platform program's memory leaks will mostly
be based on malloc (it couldn't use SysV's IPC and still be
cross-platform, for example; and while mmap might be a possibility,
perhaps it might be tracked by a similar trick as malloc might).


> In the real world, malloc() and mmap() are probably sufficient to get a
> good picture of process usage for most processes.  But I guess defining
> exactly what counts as the process' current memory would be a starting
> place (specifically how to deal with shared memory).

Considering that the main purpose is adding regression tests to confirm
that a hopefully-fixed memory leak does not recur, I'm not sure why
shared memory should be a problem.  What scenarios would "leak shared
memory"?  If some shared library gets loaded once and stays in memory
that doesn't appear to me as something that would normally be called "a
memory leak" -- unless I'm failing to see some cross-platform scenario
that would erroneously re-load the same library over and over again,
taking up growing amounts of shared memory with time?


Alex