Thread: Memory Analyzer Tool

  1. #1
    Registered User
    Join Date
    Feb 2008
    Posts
    146

    Memory Analyzer Tool

    I need to have some memory analyzer tool which can detect memory leaks in a program (especially a multithreaded program)... is there any such tool available?

  2. #2
    Registered User
    Join Date
    Jan 2007
    Location
    Euless, TX
    Posts
    144
    Take a look on zdnet.com for software that adresses memory leaks. You can do a search fo "memory leak" and see what turns up. Be prepared to spend money. I doubt if you will find a very good one for free.

  3. #3
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Quote Originally Posted by kcpilot View Post
    Take a look on zdnet.com for software that adresses memory leaks. You can do a search fo "memory leak" and see what turns up. Be prepared to spend money. I doubt if you will find a very good one for free.
    You're in luck, valgrind is very good and free.

  4. #4
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Assuming you run Linux .

    It's one of a few great Linux open source programs not ported to Windows. Porting valgrind would probably be like a rewrite anyways, since it's very "close to metal".

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Just be aware of this:

    malloc doubt

    which may apply to the ptheads library, meaning valgrind will be no good.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    Registered User
    Join Date
    Feb 2008
    Posts
    146
    yes, I am running linux but to be precise I want to use this memory analyzer tool for an embedded application which uses MontaVista Linux Pro 2.1.

    Googling it, I got to know that MVPro has a memory debugger facility called mtrace for which I need to use following steps :

    • include the mcheck.h header file
    • place a call to mtrace() at the beginning of the program
    • place a call to muntrace() at the end of the program
    • re-compile your code (be sure to use the -g debug option)
    • at the command prompt , type export MALLOC_TRACE=mtrace.log
    • re-run the program


    Doing so does not even generate mtrace.log. I am not so sure what may be wrong. Also is it possible to use valgrind on MVPro?

  7. #7
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Valgrind only supports x86(-64), so that won't help.

  8. #8
    Registered User
    Join Date
    Feb 2008
    Posts
    146

    mtrace

    ok...if anyone using mtrace can suggest what may be the problem, it will be great help...

  9. #9
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    It's not hard to write your own thin layer to check for memory leaks. Whenever you allocate something, store the address and size in an array somewhere. When you deallocate, scan the array and clear the corresponding entry.

    At the end of the program, the array will contain each memory block that was leaked.

    (Yes, it slows your program down, just like any other good debugging aid.)
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  10. #10
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    [off-topic]
    By the way:
    Valgrind I believe calls anything not freed() lost memory, which makes valgrind very dumbass in my book. As brewbuck hints at, there are numerous very widely used libraries which do not pointlessly free() memory "at exit" rendering valgrind useless for mem profiling applications which use those libraries.
    Not useless. You just need a little creativity.

    I use valgrind to check SDL programs for memory leaks, for example. The SDL, however, leaks memory just as you have described. So I wrote a Perl script to remove those lines from the output . . . (note, this script is pretty old, hopefully I'd do a better job if I wrote it now!)
    Code:
    #!/usr/bin/perl
    # Script to strip internal SDL errors and memory leaks from the output of
    # Valgrind.
    #
    # Written by DWK.
    
    use strict;
    use warnings;
    
    my %options = (
        'strip-minuses' => 1
    );
    
    &parse_arguments();
    &process_data();
    
    sub parse_arguments {
        foreach my $arg (@ARGV) {
            foreach my $option (keys %options) {
                if($arg eq "--$option") {
                    $options{$option} = 1;
                }
                elsif($arg eq "--no-$option") {
                    $options{$option} = 0;
                }
                elsif($arg =~ /--$option=(\d+)$/) {
                    $options{$option} = int($1);
                }
            }
        }
    }
    
    sub process_data {
        my @data = <>;
        my $name = $0;
        
        $name =~ s|^.*[/\\]||;
        
        &strip_sdl($name, @data);
        &extract_summary($name, @data);
    }
    
    sub extract_summary {
        my ($name, @data) = @_;
        
        print "SUMMARY\n";
        
        foreach my $line (@data) {
            if($line =~ /^==\d+==\s*(malloc\/free: .*)$/) {
                print "    $1\n";
            }
        }
    }
    
    sub strip_sdl {
        my ($name, @data) = @_;
        my $lastpos = -1;
        
        for(my $x = 0; $x < @data; $x ++) {
            if($data[$x] =~ /^==\d+==\s*$/ || $data[$x] =~ /^--\d+--/) {
                if($lastpos >= 0) {
                    @data = &parse_section($name, $lastpos, $x, @data);
                }
                
                $lastpos = -1;
            }
            elsif($data[$x] =~ /^==\d+==    at/) {
                if($lastpos >= 0) {
                    @data = &parse_section($name, $lastpos, $x - 1, @data);
                }
                
                $lastpos = $x - 1;
            }
        }
        
        &print_data(@data);
    }
    
    sub print_data {
        my @data = @_;
        
        foreach my $line (@data) {
            if($line =~ /^--\d+--/ && $options{'strip-minuses'} == 1) {
                next;
            }
            
            print $line;
        }
    }
    
    sub parse_section {
        my ($name, $start, $end, @data) = @_;
        my $funcs = '(__|_X|SDL_(Init|Quit|LoadObject|LoadFunction|VideoInit))';
        my $x = 0;
        
        for($x = $start; $x < $end; $x ++) {
            if($data[$x] =~ /^==\d+==    by 0x[\d\w]+: $funcs/) {
                last;
            }
        }
        
        if($x < $end) {
            if($start) {
                if($data[$start - 1] =~ /^==\d+==\s*$/) {
                    $data[$start - 1] = '';
                }
                elsif($data[$start - 1]
                    =~ /^==\d+== \d+ errors in context \d+ of \d+:$/) {
                    
                    $start --;
                    $data[$start] =~ s/^==\d+==\s*//;
                    $data[$start] = "HEAD:  $data[$start]";
                    $start ++;
                }
            }
            
            $data[$start] =~ s/^==\d+==\s*//;
            $data[$start] = "STRIP: $data[$start]";
            $start ++;
            
            if($end < @data && $data[$end] =~ /^==\d+==\s*$/) {
                $data[$end] = '';
            }
            
            do {
                $data[$start] = '';
            } while(++$start != $end);
        }
        
        return @data;
    }
    Then I get output like this:
    Code:
    ...
    STRIP: 368 bytes in 1 blocks are still reachable in loss record 41 of 64
    STRIP: 408 bytes in 1 blocks are still reachable in loss record 42 of 64
    STRIP: 480 bytes in 4 blocks are still reachable in loss record 43 of 64
    STRIP: 624 bytes in 7 blocks are still reachable in loss record 44 of 64
    STRIP: 702 bytes in 54 blocks are still reachable in loss record 45 of 64
    STRIP: 802 bytes in 88 blocks are still reachable in loss record 46 of 64
    ==10304==
    ==10304== 840 bytes in 1 blocks are still reachable in loss record 47 of 64
    ==10304==    at 0x4C216F4: calloc (vg_replace_malloc.c:397)
    ==10304==    by 0x571F62B: _mxml_global (in /usr/lib/libmxml.so.1.4)
    ==10304==    by 0x571BD6A: mxmlSetErrorCallback (in /usr/lib/libmxml.so.1.4)
    ==10304==    by 0x46F410: Callis::Resource::ResourceFile::ResourceFile(std::stri
    ng) (ResourceFile.cpp:23)
    ==10304==    by 0x46C178: Callis::Resource::UniverseParserWrapper::UniverseParse
    rWrapper(std::string, std::string) (UniverseParser.h:44)
    ==10304==    by 0x468CEA: main (RoleplayMain.cpp:19)
    ==10304==
    STRIP: 880 bytes in 55 blocks are still reachable in loss record 48 of 64
    STRIP: 1,024 bytes in 1 blocks are still reachable in loss record 49 of 64
    STRIP: 1,092 bytes in 91 blocks are still reachable in loss record 50 of 64
    STRIP: 1,117 bytes in 55 blocks are still reachable in loss record 51 of 64
    STRIP: 1,341 bytes in 91 blocks are still reachable in loss record 52 of 64
    ...
    which lets me see the memory leaks that are actually my fault.
    [/off-topic]
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 06-02-2009, 08:57 PM
  2. Problems with shared memory shmdt() shmctl()
    By Jcarroll in forum C Programming
    Replies: 1
    Last Post: 03-17-2009, 10:48 PM
  3. Accessing Video Memory Information...need help
    By KneeLess in forum C++ Programming
    Replies: 8
    Last Post: 08-24-2003, 03:53 PM
  4. Memory handler
    By Dr. Bebop in forum C Programming
    Replies: 7
    Last Post: 09-15-2002, 04:14 PM
  5. What's the best memory (RAM) type?
    By Unregistered in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 12-15-2001, 12:37 AM