System-API to get current process memory usage for C/C++ pgm?

[Matt]

What if any system calls exist to get the current process' system
memory usage (including all of the current process' threads) in a
C/C++ based program?

I'm trying to write unit tests to make sure that my memory allocation
processes (for Boost "smart pointers") are actually deallocating
correctly after thousands of dynamic allocations...and my presumption
is that a current-process-memory-usage "self check" will be very
useful for my self-running unit test.

I'd prefer cross-platform calls (be it POSIX, unix/linux, Boost C++,
etc) if I can get them, but I'll take a system specific all (for my
testing prototype) if I must.

Thanks for any help,
-Matt
--
Remove the "downwithspammers-" text to email me.

[Thomas Maier-Komor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Your assumption is incorrect concerning the virtual memory of a process.
A call to free() does not enforce memory mapped to a programs virtual
memory space to be unmapped. I.e. your program might do thousands of
mallocs and the exact number of frees and everything is fine, but your
program's virtual memory size is higher after the free as before the
mallocs.

I think you should take a look at the various tools available for
debugging memory related problems. Under Linux valgrind and efence might
get you started and under Solaris there is libumem (take a look at
umem_debug(3malloc)).

The only thing that could give you a portable solution is to write your
own mallocs and frees and use either sbrk() or mmap() to allocate new
address space. Before doing so, I suggest going to opensolaris.org and
taking a look at the libumem source code.

HTH,
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEGM5R6U+hp8PKQZIRAqkrAKD0yPAIss7jgj2KZhpvhPDWzH+MbACg7wO7
ViL0h8N9Ktn2TlmdidsrUMM=
=pucF
-----END PGP SIGNATURE-----

[Ian Collins]

I do this with my own operators new() and delete(). This assumes that
you don't use malloc in your C++.

If you use Solaris, the dbx debugger can do this for you on exit.

--
Ian Collins.

[Gordon Burditt]

>What if any system calls exist to get the current process' system
>memory usage (including all of the current process' threads) in a
>C/C++ based program?

It's difficult to use this number for anything meaningful. In
particular, free() is unlikely to reduce it, since free()d memory
is usually (depending on the system) made available for reallocation
by this process itself, not given back to the OS.

>I'm trying to write unit tests to make sure that my memory allocation
>processes (for Boost "smart pointers") are actually deallocating
>correctly after thousands of dynamic allocations...and my presumption
>is that a current-process-memory-usage "self check" will be very
>useful for my self-running unit test.

A debugging version of malloc/free that tracks memory usage
would be much more helpful than something that tries to track *ALL*
memory usage.

>I'd prefer cross-platform calls (be it POSIX, unix/linux, Boost C++,
>etc) if I can get them, but I'll take a system specific all (for my
>testing prototype) if I must.

On some systems, you could get an approximation of this number from
sbrk(0). It's almost completely useless for tracking whether you forgot
to free() something. The part that isn't useless involves putting
whatever code in a loop and testing if the value continues to go up
indefinitely.

Gordon L. Burditt

[David Schwartz]

"Gordon Burditt" <gordon...@burditt.org> wrote in message
news:121hofa...@corp.supernews.com...

> It's difficult to use this number for anything meaningful. In
> particular, free() is unlikely to reduce it, since free()d memory
> is usually (depending on the system) made available for reallocation
> by this process itself, not given back to the OS.

Note that this is *virtual* memory he is talking about here, not
physical memory.

DS

[Alan Woodland]

Matt wrote:
> What if any system calls exist to get the current process' system
> memory usage (including all of the current process' threads) in a
> C/C++ based program?

There's an XPG/SVID extension that sounds like it might be what you're
looking for. GNU C library includes it:

http://www.gnu.org/software/libc/manual/html_node/Statistics-of-Malloc.html#Statistics-of-Malloc

Alan

[Gordon Burditt]

>> It's difficult to use this number for anything meaningful. In
>> particular, free() is unlikely to reduce it, since free()d memory
>> is usually (depending on the system) made available for reallocation
>> by this process itself, not given back to the OS.
>
> Note that this is *virtual* memory he is talking about here, not
>physical memory.

And so am I. free() is unlikely to give back memory, physical or
virtual, to the OS.

Some of the reasons include (1) parts of the page may still be in
use, (2) an OS that uses sbrk() can only return the last memory
allocated, (3) mmap() aligns stuff by pages and the only really
practical way to be able to release memory is to use one mmap() per
request, but it wastes so much memory for small (e.g. less than 4
pages worth) requests it's not practical, and (4) hanging on to the
memory in the process for later re-use is considered an optimization
which is usually effective but can be pathological in corner cases.

Gordon L. Burditt