Opened 12 years ago

Closed 12 years ago

#33745 closed defect (invalid)

Valgrind fails to show file/line of leak/error

Reported by: ClintO (Clint O) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone:
Component: ports Version: 2.0.4
Keywords: Cc: neverpanic (Clemens Lang)
Port: valgrind

Description (last modified by neverpanic (Clemens Lang))

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.

Change History (8)

comment:1 Changed 12 years ago by neverpanic (Clemens Lang)

Cc: cal@… added
Description: modified (diff)
Keywords: valgrind g++ removed
Owner: changed from macports-tickets@… to raimue@…

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?

comment:2 in reply to:  1 Changed 12 years ago by 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?

comment:3 Changed 12 years ago by 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++?

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by ClintO (Clint O)

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

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by neverpanic (Clemens Lang)

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.