Valgrind fails to show file/line of leak/error

[ClintO (Clint O)]

I have a small piece of C++ software that demonstrates leaks, but for whatever reason I cannot coax the file and line numbers. I used /usr/bin/g++ -g -W -Wall to compile every source. Some sources were generated by flex and bison, but otherwise it's just straightforward C++.

==985== 96 bytes in 4 blocks are definitely lost in loss record 13 of 22
==985==    at 0xB823: malloc (vg_replace_malloc.c:266)
==985==    by 0x5768D: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==985==    by 0x100003BB5: yylex(YYSTYPE*, void*) (in ./re)
==985==    by 0x1000016C7: yyparse(Parser*, void*) (in ./re)
==985==    by 0x10000291C: main (in ./re)

I attempted to reproduce with the following piece of C++ code, but it works. So, there's some difference between the two cases:

$ cat leak.cpp 
class Foo {
    const char *name;
    int    age;

    public:

    Foo(const char *name_, int age_) : name(name_), age(age_) {};

};

int main(int argc, char *argv[])
{

    Foo *foo = new Foo("foo", 1);

    foo = new Foo("bar", 2);

    return 0;
}
$ g++ -W -Wall -g -o leak leak.cpp 
leak.cpp:11: warning: unused parameter ‘argc’
leak.cpp:11: warning: unused parameter ‘argv’

$ valgrind --leak-check=full ./leak
==1299== Memcheck, a memory error detector
==1299== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==1299== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==1299== Command: ./leak
==1299== 
==1299== 
==1299== HEAP SUMMARY:
==1299==     in use at exit: 2,229 bytes in 34 blocks
==1299==   total heap usage: 34 allocs, 0 frees, 2,229 bytes allocated
==1299== 
==1299== 16 bytes in 1 blocks are definitely lost in loss record 2 of 10
==1299==    at 0xB823: malloc (vg_replace_malloc.c:266)
==1299==    by 0x5768D: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==1299==    by 0x100000E56: main (leak.cpp:14)
...

Any suggestions you may have would be much appreciated.

[neverpanic (Clemens Lang)]

Please use WikiFormatting and remember to Cc the maintainer.

Is there a re.dSYM directory next to the re binary? Does dwarfdump re.dSYM list the source code and debug symbols?

[ClintO (Clint O)]

Replying to cal@…:

Please use WikiFormatting and remember to Cc the maintainer.

Is there a re.dSYM directory next to the re binary? Does dwarfdump re.dSYM list the source code and debug symbols?

There is no directory with debugging symbols and dwarfdump returns empty. Which step compile/link produces this?

[neverpanic (Clemens Lang)]

The compiler should when compiling with debug symbols (-g). Which compiler are you using? It works fine for me with i686-apple-darwin11-llvm-g++-4.2 and Apple clang version 3.1 (tags/Apple/clang-318.0.45). Can you also try with clang++?

[ClintO (Clint O)]

I'm using /usr/bin/g++ on Lion. The weird thing is that if I do the simple example it works fine. It's only my slightly more complex build that's not working.

[neverpanic (Clemens Lang)]

Well, unfortunately unless I can reproduce the issue with an example that doesn't work, there's not much I can do.

[ClintO (Clint O)]

I'll fiddle around to see what's happening. I don't have great internet connectivity at the moment.

[ClintO (Clint O)]

Ok, I apologize for the thrash. Apparently if you use anything other than a trivial single-file build, dsymutil needs to be run as a separate step in order to get gcc to generate the exe.dSYM directory. I have no idea why they changed this, but it's really silly and counterintuitive:

​http://stackoverflow.com/questions/4850788/prevent-compiling-from-generating-dsym-on-os-x-using-make

So, I have my answer, and there's nothing wrong with valgrind. Thanks for your patience.

[neverpanic (Clemens Lang)]

You can try running valgrind with --dsymutil=yes and see if that helps.