Memory consumption

Discussion in 'C Programming' started by MN, Mar 12, 2009.

  1. MN

    MN Guest

    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.
     
    MN, Mar 12, 2009
    #1
    1. Advertising

  2. MN wrote:
    > 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' ?
     
    Edwin van den Oetelaar, Mar 12, 2009
    #2
    1. Advertising

  3. MN <> wrote:
    > 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
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Mar 12, 2009
    #3
  4. MN wrote:
    > 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
     
    Joachim Schmitz, Mar 12, 2009
    #4
  5. On 12 Mar 2009 at 18:40, Joachim Schmitz wrote:
    > MN wrote:
    >> 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().


    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...
     
    Antoninus Twink, Mar 12, 2009
    #5
  6. MN

    CBFalconer Guest

    Joachim Schmitz wrote:
    > MN wrote:
    >
    >> 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.


    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>

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Mar 13, 2009
    #6
  7. Han from China wrote:
    > CBFalconer wrote:
    >> nmalloc is quite general, and should mount on any system that
    >> supplies sbrk to access memory.

    >
    > 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
     
    Joachim Schmitz, Mar 13, 2009
    #7
  8. In article <>,
    Han from China <> wrote:
    >Joachim Schmitz wrote:
    >> Han from China wrote:
    >>> 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"

    >
    >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.
     
    Kenny McCormack, Mar 13, 2009
    #8
  9. MN

    Kaz Kylheku Guest

    On 2009-03-13, Joachim Schmitz <> wrote:
    > Han from China wrote:
    >> CBFalconer wrote:
    >>> nmalloc is quite general, and should mount on any system that
    >>> supplies sbrk to access memory.

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


    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.
     
    Kaz Kylheku, Mar 13, 2009
    #9
  10. MN

    CBFalconer Guest

    Kaz Kylheku wrote:
    > Joachim Schmitz <> wrote:
    >> Han from China wrote:
    >>> CBFalconer wrote:
    >>>
    >>>> nmalloc is quite general, and should mount on any system that
    >>>> supplies sbrk to access memory.
    >>>
    >>> 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"

    >
    > 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Mar 14, 2009
    #10
  11. MN

    Kaz Kylheku Guest

    On 2009-03-14, CBFalconer <> wrote:
    > References: [...] <> [.. ]
    > Kaz Kylheku wrote:


    And so the mental killfile breaks down. Amazing endurance. Is this a new
    personal best for Chucky? Judges?
     
    Kaz Kylheku, Mar 14, 2009
    #11
  12. Han from China wrote:
    > Joachim Schmitz wrote:
    >> Han from China wrote:
    >>> 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"

    >
    > 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, Mar 14, 2009
    #12
  13. Han from China wrote:
    > Joachim Schmitz wrote:
    >>> Falconer won't complain, right?

    >>
    >> Probably not

    >
    > 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, Mar 15, 2009
    #13
  14. Richard wrote:
    > "Joachim Schmitz" <> writes:
    >
    >> Han from China wrote:
    >>> Joachim Schmitz wrote:
    >>>> Han from China wrote:
    >>>>> 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"
    >>>
    >>> 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

    >
    > 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, Mar 15, 2009
    #14
  15. Richard Heathfield wrote:
    > Joachim Schmitz said:

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

    >
    > 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.
     
    Joachim Schmitz, Mar 15, 2009
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Duccio
    Replies:
    0
    Views:
    545
    Duccio
    Feb 25, 2006
  2. Kiran Kumar

    aspnet_wp.exe memory consumption

    Kiran Kumar, Jul 15, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    468
    Natty Gur
    Jul 15, 2003
  3. Ervin

    Urgent! GDI+ Memory consumption

    Ervin, Sep 15, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    628
    Ervin
    Sep 15, 2003
  4. tony_wang
    Replies:
    1
    Views:
    4,097
    Saravana [MVP]
    Nov 21, 2003
  5. Jim Campbell
    Replies:
    1
    Views:
    978
    Ashish
    Feb 12, 2004
Loading...

Share This Page