Question

Even after introducing an intentional memory leak valgrind shows:

==13483== HEAP SUMMARY:
==13483==     in use at exit: 0 bytes in 0 blocks
==13483==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13483== 
==13483== All heap blocks were freed -- no leaks are possible

The executable was compiled with G++ 4.1.2 and 4.6.2 with:

g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -pthread -Wno-long-long -Wno-uninitialized <snipped definitions and include directives from the build system>

I’ve tried with Valgrind 3.5.0 and 3.6.1 like:

valgrind --leak-check=full --undef-value-errors=no --show-reachable=yes <executable args>

Within the framework of the library I’m working on, I’m using a simple test case:

#include "pwiz/utility/misc/Std.hpp"
#include "pwiz/utility/misc/Filesystem.hpp"
#include "pwiz/data/identdata/IdentDataFile.hpp"

using namespace pwiz::cv;
using namespace pwiz::data;
using namespace pwiz::identdata;
using namespace pwiz::util;

int main(int argc, char** argv)
{
    vector<string> args(argv+1, argv+argc);
    BOOST_FOREACH(const bfs::path& filename, args)
    {
        // intentional memory leak
        IdentDataFile* idp = new IdentDataFile(filename.string());
        IdentDataFile& id = *idp;
        cout << filename.string() << " "
             << id.analysisCollection.spectrumIdentification[0]->activityDate << " "
             << id.analysisCollection.spectrumIdentification[0]->spectrumIdentificationListPtr->spectrumIdentificationResult.size()
             << "\n";
    }
    return 0;
}

Obviously I don’t expect others to be able to compile this, but anyway I suspect it’s something about the library that’s tripping up valgrind so a simpler test case would be pointless. And I know that the for loop is being executed because I get the cout output during Valgrind execution. How can I debug it without simplifying further?

Answer 1

It boiled down to the linker options actually. I was compiling with -static, so valgrind did not have a chance to substitute its own malloc implementation. Unfortunate that valgrind doesn’t at least warn about this though!