3

I have a very simple C++ program.

#include <iostream>

int main()
{
    std::cout << "HI" << std::endl;
    return 0;
}

I compile this on a Mac with the command c++ --std=c++11 leak.cpp.

When I debug this with valgrind --leak-check=full ./a.out, I get the following output:

==2187== HEAP SUMMARY:
==2187==     in use at exit: 38,906 bytes in 429 blocks
==2187==   total heap usage: 508 allocs, 79 frees, 45,074 bytes allocated
==2187== 
==2187== LEAK SUMMARY:
==2187==    definitely lost: 0 bytes in 0 blocks
==2187==    indirectly lost: 0 bytes in 0 blocks
==2187==      possibly lost: 0 bytes in 0 blocks
==2187==    still reachable: 4,096 bytes in 1 blocks
==2187==         suppressed: 34,810 bytes in 428 blocks
==2187== Reachable blocks (those to which a pointer was found) are not shown.
==2187== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Turns out there are 4096 bytes that are "still reachable". If I remove the cout statement then there are no more "still reachable" bytes.

Why is it the case that outputting to std::cout causes a memory leak?

geoff
  • 2,251
  • 1
  • 19
  • 34
  • Have you tried [this](http://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream) ? – doqtor May 26 '15 at 21:29

1 Answers1

3

It could be a false positive in the leak report. Valgrind can only be so clever; your standard library implementation is taking certain liberties that Valgrind doesn't have a special case for.

I'd be more worried about figuring out why this tiny program is performing 508 allocations, to a total of 45,074 bytes.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055