Memory consumption

[MN]

Hello,
Is there any c function or command under linux that reports statistics
for a given program, that uses memory allocation? specially, what I
want is to know memory used when running program.

 

[Edwin van den Oetelaar]

Hello,
Is there any c function or command under linux that reports statistics
for a given program, that uses memory allocation? specially, what I
want is to know memory used when running program.

you mean 'top' or 'htop' ?

 

[Jens Thoms Toerring]

Is there any c function or command under linux that reports statistics
for a given program, that uses memory allocation? specially, what I
want is to know memory used when running program.

There's no standard C function for this. You will have to
resort to system specific functions and thus better ask
in e.g. comp.unix.pogrammer. But note that the same ques-
tion was asked there a few days ago (March 5th, by Rui
Maciel, "Measure program memory usage?"). And the summary
of the answers is that on modern systems, especially those
that use virtual memory, there is no simple answer - do you
mean virtual memory or physical memory? What about memory
you malloc()ed but did not yet use and thus may not be map-
ped physically into the address space of your process? Do
you count in the memory used for shared libraries that are
also used by other processes at the same time etc.?

Regards, Jens

 

[Joachim Schmitz]

Hello,
Is there any c function or command under linux that reports statistics
for a given program, that uses memory allocation? specially, what I
want is to know memory used when running program.

You system/implementation may have the non-standard mallinfo(). The GNU
C-Library for example provides it as does IBM, SUN, HP, SGI.
Check your documentation.

Bye, Jojo

 

[Antoninus Twink]

You system/implementation may have the non-standard mallinfo().

You may also be able to find out the total memory usage of your process
from the kernel: for example, on Linux you could investigate
/proc/<pid>/status.

Whatever method you use, how useful the information you'll get will be
is another question...

 

[CBFalconer]

You system/implementation may have the non-standard mallinfo().
The GNU C-Library for example provides it as does IBM, SUN, HP,
SGI. Check your documentation.

My implementation of malloc for DJGPP, nmalloc, also includes a
malldbg module that provides that same facility (and others).
nmalloc is quite general, and should mount on any system that
supplies sbrk to access memory. It also assumes at least CHAR_BIT
== 8 and 32 bit integers. See:

<http://cbfalconer.home.att.net/download/nmalloc.zip>

 

[Joachim Schmitz]

I don't see sbrk() in my copy of the C standard.

That's most probably why he wrote: "on any system that supplies sbrk"

Bye, Jojo

 

[Kenny McCormack]

Right. So if people start providing Web links to software that uses,
say, POSIX threads, with the comment "should work on any system that
supplies POSIX threads", Falconer won't complain, right?

Exactly. In the dogma of this group, any mention of things deemed "off
topic" by the ruling clan, is met with an immediate rubuke (or several).

Except, of course, if it is done by one of the ruling clan.

You don't need to answer that. The answer is already available in
the archives, where he's seen bitching at people who post links to
code that uses non-ISO features. He's a hypocritical Net Nannying
piece of shit.

And you're being kind.

 

[Kaz Kylheku]

That's most probably why he wrote: "on any system that supplies sbrk"

If you muck around with sbrk, you may break your malloc implementation, so your
malloc should replace it completely.

The malloc implementation in glibc is defensively coded against this. It will
notice that someone has moved the break location behind its back. After that,
it will continue to work, but it will not be able to return memory to the
operating system when the program calls free (at least not from the principal
heap). This is a lucky case. Another malloc implementation might simply not
bother to check whether sbrk has moved. Once you use brk or sbrk, you can't
use malloc. Your allocator should provide a complete replacement which is used
by everything in the address space.

Any halfway sane do-it-yourself allocator targetting Unix uses anonymous mmap
for grabbing memory.

Now the above are just my hacker intuitions. But what does the Single Unix
Specification actually say? What do you know. It denotes these functions as
legacy interfaces. As in, obsolete junk. Do not use. And---aha!---there is
this text:

The behaviour of brk() and sbrk() is unspecified if an application
also uses any other memory functions (such as malloc(), mmap(),
free()). Other functions may use these other memory functions silently.

There you go.

 

[CBFalconer]

If you muck around with sbrk, you may break your malloc
implementation, so your malloc should replace it completely.

The malloc implementation in glibc is defensively coded against
this. ...

You obviously have not read the source of nmalloc.

 

[Kaz Kylheku]

References: [...] <[email protected]> [.. ]
Kaz Kylheku wrote:

And so the mental killfile breaks down. Amazing endurance. Is this a new
personal best for Chucky? Judges?

 

[Joachim Schmitz]

Right. So if people start providing Web links to software that uses,
say, POSIX threads, with the comment "should work on any system that
supplies POSIX threads", Falconer won't complain, right?

Probably not, so seems you're right for a change

You don't need to answer that.

Oops, too late

Bye, Jojo

 

[Joachim Schmitz]

Well, the archives reveal that you're most probably wrong.

ahem, sorry, double negate got me. As you coule have spotted by the rest of
that line, which you snipped. Restored here:

Probably not, so seems you're right for a change

So the 'not' shouldn't heve been there.

Bye, Jojo

 

[Joachim Schmitz]

Sorry? What? Do you have Chuck killfiled?

No. I'me the proud owner of an empty killfile. I don't need to rely on a
machine to decide what I read, see and reply to or not.

The 'not' was simply a mistake, as could have been easily deducted from the
rest of that sentence.

Bye, Jojo

 

[Joachim Schmitz]

Joachim Schmitz said:

Whilst it would certainly be convenient to be able to deduct
(subtract) mistakes from sentences, I think you meant "deduce"
(conclude in a logical fashion).

Yes, thanks.