Thread: Does anybody else including <iostream> give them a memory leak?

  1. #1
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665

    Does anybody else including <iostream> give them a memory leak?

    For some reason, valgrind is giving me a memory leak whenever I include <iostream>.

    Consider this program:
    Code:
    #include <iostream>
    
    
    int main(void)
    {
      return 0;
    }
    Compiled with :
    Code:
    g++ -o leak leak.cpp
    Valgrind gives me the following:
    Code:
    valgrind ./leak
    ==13689== Memcheck, a memory error detector
    ==13689== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
    ==13689== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
    ==13689== Command: ./leak
    ==13689== 
    ==13689== 
    ==13689== HEAP SUMMARY:
    ==13689==     in use at exit: 72,704 bytes in 1 blocks
    ==13689==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
    ==13689== 
    ==13689== LEAK SUMMARY:
    ==13689==    definitely lost: 0 bytes in 0 blocks
    ==13689==    indirectly lost: 0 bytes in 0 blocks
    ==13689==      possibly lost: 0 bytes in 0 blocks
    ==13689==    still reachable: 72,704 bytes in 1 blocks
    ==13689==         suppressed: 0 bytes in 0 blocks
    ==13689== Rerun with --leak-check=full to see details of leaked memory
    ==13689== 
    ==13689== For counts of detected and suppressed errors, rerun with: -v
    ==13689== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    Info:
    OS: Ubuntu 14.04
    g++: 4.8.4
    valgrind: 3.10.1

    Edit: I did download gcc 5.1 yesterday though and install so maybe it's actually the 5.1 version of iostream that's giving me this leak. I get it with both versions of the compiler, 4.8.4 and 5.1 and that might be because they're both referencing the same 5.1 <iostream>.
    Last edited by MutantJohn; 01-10-2016 at 03:35 PM.

  2. #2
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,616
    Leaks in the still reachable category are just items that were allocated, but not freed before the program terminated. You could argue that these are not true leaks, because if you wanted, you could just free. The other side of the coin is that you want to detect "still reachable" allocations that could grow indefinitely - which I guess the I/O library is not going to do. And at any rate the OS would reclaim any unused items in still reachable blocks.

  3. #3
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Quote Originally Posted by whiteflags View Post
    Leaks in the still reachable category are just items that were allocated, but not freed before the program terminated. You could argue that these are not true leaks, because if you wanted, you could just free. The other side of the coin is that you want to detect "still reachable" allocations that could grow indefinitely - which I guess the I/O library is not going to do. And at any rate the OS would reclaim any unused items in still reachable blocks.
    Okay, great!

    I was also just curious if other people had noticed the same behavior. I figured C++14 might be worth trying because you can use std::get to access elements of tuples and pairs by type and so I downloaded 5.1 and gave it a shot.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Memory leak
    By ssharish2005 in forum General Discussions
    Replies: 35
    Last Post: 07-05-2011, 11:10 PM
  2. Replies: 2
    Last Post: 09-28-2006, 01:06 PM
  3. Is this a memory leak?
    By cboard_member in forum C++ Programming
    Replies: 9
    Last Post: 07-20-2005, 01:15 PM
  4. Including iostream.h
    By DvdHeijden in forum C++ Programming
    Replies: 7
    Last Post: 01-15-2005, 12:23 PM
  5. memory leak
    By gatli in forum C++ Programming
    Replies: 4
    Last Post: 09-19-2001, 09:07 AM