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

[sjdevnull]

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"?

Apache leaks SHM segments in some scenarios. SysV SHM segments aren't
freed explicitly when the process exits. They're easy enough to clean
up by hand, but it's nicer to avoid that.

 

[Serge Orlov]

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.

I've also successfully used Electric Fence many years ago to track down
leaks in a C/Linux program. Since that time Electric Fence has been
forked into DUMA project http://duma.sourceforge.net/ and was ported to
windows, perhaps it has become cross-platform? I've never tried it on
anything besides Linux.

 

[RalfGB]

Definitely looks promising, thanks for the pointer.


It appears that all of this stuff is barely documented (if at all), not
just online but also in books on advanced MacOS X programming. Still, I
can research it further, since, after all, the opendarwin sources ARE
online. Thanks again!


Alex

"mallinfo" is available on most UNIX-like systems(Linux, Solaris, QNX,
etc.) and is also included in the dlmalloc library (which works on
win32).

There is a small C extension module at
http://hathawaymix.org/Software/Sketches/
which should give access to mallinfo() and thus byte accurate memory
usage information.

I have to admit, that I did not tried it myself...

 

[mickie.liu]

"mallinfo" is available on most UNIX-like systems(Linux, Solaris, QNX,
etc.) and is also included in the dlmalloc library (which works on
win32).

There is a small C extension module at
http://hathawaymix.org/Software/Sketches/
which should give access to mallinfo() and thus byte accurate memory
usage information.

I have to admit, that I did not tried it myself...

I tried it, it doesn't work for dlmalloc.
Got to find somewhere else.
Does any body know how to report correct memory usage if using dlmalloc
package ?

Thanks in advance.

Mickie

 

[Fredrik Lundh]

I tried it, it doesn't work for dlmalloc.
Got to find somewhere else.

dlmalloc supports the mallinfo API unless you compile it with the
NO_MALLINFO option. see the comments in the beginning of
the malloc.c file for details.

Does any body know how to report correct memory usage if using dlmalloc
package ?

make sure you have a dlmalloc that has mallinfo support enabled. when you've
done that, define "doesn't work for dlmalloc" (build problems, exceptions, crashes,
compiler errors, ... ???)

</F>

 

[MrJean1]

Did you try the function I posted on Nov 15? It returns the high water
mark, like sbrk(0) and works for RH Linux (which is dlmalloc, AFAIK).

/Jean Brouwers

PS) Here is that code again (for RH Linux only!)

size_t hiwm (void) {
/* info.arena - number of bytes allocated
* info.hblkhd - size of the mmap'ed space
* info.uordblks - number of bytes used (?)
*/
struct mallinfo info = mallinfo();
size_t s = (size_t) info.arena + (size_t) info.hblkhd;
return (s);
}