Magic with memusage library in linux

Today, I have started writing a tool for finding memory leaks in my programs. So, I have started with defining my own memory functions like malloc, realloc, free with exactly same signature as of the original memory functions. In these functions, I explicitly load original memory libraries, call the original functions and I keep note of how many times each of them is called. So, if I wanted to find memory leaks in a program test, instead of executing it like $./test, I would execute it like $LD_PRELOAD=$PWD/libmemleaks.so ./test.

By mistake, I was explicitly loading /lib/libmemusage.so instead of libc.so. Initially I got so many compilation errors in my libmemleaks.so program. So, I removed lot of code and compiled it again succesfully. But, when I executed it finally, I got a table with heap/stack size and no.of times malloc/calloc/free are called. The table is shown below.memory_report

Surprised!! I was not expecting this multi-colored table. I did not write any code for printing this table. In yahoo/google, I searched and did not get any references to this problem [no documentation, problem with open source??]. Then I have used google code search and searched for “Memory usage summary” and got a link to glibc-2.2.5/malloc/memusage.c. After seeing that file, in _fini function, I understood that, they are writing the memory usage report. _fini is the function in shared library which is called, when the system is unloading the library.

After that, I have download glibc 2.2.5 source code and started looking for the clues. In the same directory as glibc-2.2.5/malloc, I found a shell script memusage.sh file. I have copied that into my linux machine and modified a line and executed it [sh memusage.sh ./test]. Then, I got the same multi colored table. Then I came to know, this memusage.so library is written for getting memory stats. memusage.sh, internally executes like LD_PRELOAD= /lib/libmemusage.so <prog.name>. Even I thought of writing my memory leak checking tool with the same concept and at last I have completed my program. But, my program is not as colorful as memusage.sh program. Using memusage.sh, we can find memory stats of any program [including java programs]. Execute sh memusage.sh –help for command help.

Normally, linux distributions dont distribute memusage.sh. You can see the same shell script here. you can download it from here [I have modified at 2 places. Replaced @SLIBDIR@ , @BINDIR@ with /lib, /bin. To get graphs, you need to have memusagestat executable in /bin]. Finally, I am very happy that I found this utility after researching on this for 3 1/2 days.

Advertisements

8 Comments

  1. Sreejith said,

    October 6, 2006 at 12:02 pm

    Awesome ra. i can get a feel of the things you are creating. but i never felt this confused even after pkreddy’s class as i felt after reading this post 🙂 Its just that i am not competent to understand anything that is written here 😀 but do keep writing ra because i’ll keep reading.

  2. thaj said,

    May 29, 2008 at 9:18 pm

    I am working for Aricent. I am stucked with a mem leak. Ours is an multithreaded application. I have tried a tool (similar to urs),valgrind and mtrace() muntrace () functions….But I cant find it out. Then thought of using dmalloc library…But I need to cross compile for my target environment but that is hectic…If you have any solution plz help me out…

    Thankx n advance….
    Taj

  3. Manas said,

    August 23, 2008 at 9:48 pm

    Hi Thaj,

    May be I am responding too late to your post. But I have gone through same
    situation and have hand crafted the following solution (at two different jobs).

    Create a macro to give current virtual memory size of the program and use it at
    various places to pin point the culprit.

    One example:

    > cat MemoryStats.h

    #ifndef MEMORY_STATS_H__
    #define MEMORY_STATS_H__
    #include

    class MemoryStats {
    MemoryStats();
    public:

    static long long int VmSize() {
    FILE * fp = fopen(“/proc/self/stat”, “r”);
    const int token_num = 23;
    for (int i = 1; i vm size: %lld delta: %lld\n”,
    call_num, fname, line_num, vm_size, delta);
    }

    private:
    FILE *fp;
    };

    #if 0
    #include
    int main()
    {
    MemoryStats::Print(__FILE__, __LINE__);
    void* ptr = malloc (1024*1024);
    MemoryStats::Print(__FILE__, __LINE__);
    return 0;
    }
    #endif
    #endif // MEMORY_STATS_H__

  4. Manas said,

    August 23, 2008 at 9:53 pm

    Hi,

    This posting form ate my “<” symbols and garbled the code. If you need
    the snippet then email me jagadev@gmail.com .
    Basically it reads 23rd token in /proc/self/stat (which is same as /proc/getpid()/stat)
    to get VSZ (virtual memory size) and prints it.

    For non linux systems you can use ps command to get current VSZ size.

    The usage is to put this print at various locations of your code.

  5. josé luis said,

    February 17, 2009 at 5:33 am

    hello Durga,I have been using memusage but I don’t understand if the heap peak , stack peak,heap total is in bytes or Kb, if you can help me to interpret this i well be very grateful,thanks in advance.

  6. josé luis said,

    February 17, 2009 at 5:34 am

    Im trying to get the maximum peak of memory used by my program, I would like to compare the memory performance against another program
    In this case, which of those numbers(heap total, heap peak, stack peak) would answer my question?

    Thank you in advance

  7. DP said,

    February 24, 2009 at 11:48 pm

    Hi José,

    Heap peak, stack peak and heap total are given in bytes.

    I think heap peak and stack peak matters to you.
    Heap peak gives you the peak amount of memory allocated on heap.

    Similarly, stack peak gives you the peak point in stack.. In case, you are measuring only dynamic memory, stack peak is irrelevant. IMO, in most of the scenarios, measuring stack memory is not needed.

  8. XICO2KX said,

    March 13, 2012 at 10:10 pm

    There’s another tool named “tstime” that is also pretty useful for checking memory usage (and time usage too):
    https://bitbucket.org/gsauthof/tstime
    😉


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: