Valgrind outputs memory leaks in glog

[GoogleCodeExporter]

Compile the example from the documentation
#include <glog/logging.h>

int main( int argc, char* argv[] ) 
{
     unsigned int num_cookies = 42;

     google::InitGoogleLogging( argv[ 0 ]);

     LOG( INFO ) << "Found " << num_cookies << " cookies";
}

run the compiled binary with valgrind

Original issue reported on code.google.com by tma.kl...@gmail.com on 26 Oct 2010 at 7:21

[GoogleCodeExporter]

Sorry, I'm using this calgrind command line : 
valgrind --tool=memcheck --leak-check=full --show-reachable=yes 
--leak-resolution=high 

Original comment by tma.kl...@gmail.com on 26 Oct 2010 at 7:25

[GoogleCodeExporter]

Fixed by http://code.google.com/p/google-glog/source/detail?r=96

Original comment by shinichi...@gmail.com on 5 Sep 2011 at 8:00

• Changed state: Fixed

[GoogleCodeExporter]

Issue 104 has been merged into this issue.

Original comment by shinichi...@gmail.com on 26 Nov 2011 at 7:14

[GoogleCodeExporter]

I've applied the patch in comment 2 but still get 10 reported memory leaks in 
MSVC 2010 (2 reported leaks in MSVC 2008) using _CrtDumpMemoryLeaks().

int main(int argc, char* argv[])
{
    google::InitGoogleLogging(argv[0]);
    google::ShutdownGoogleLogging();

    // Check for memory leaks in debug builds.
    _CrtDumpMemoryLeaks();

    return 0;
}

Detected memory leaks!
Dumping objects ->
{152} normal block at 0x00415128, 8 bytes long.
 Data: <  C     > E0 04 43 01 00 00 00 00 
{151} normal block at 0x004150E0, 8 bytes long.
 Data: <  B     > 88 F5 42 01 00 00 00 00 
{144} normal block at 0x00414EE8, 8 bytes long.
 Data: <  B     > 10 C3 42 01 00 00 00 00 
{143} normal block at 0x00414EA0, 8 bytes long.
 Data: <  B     > 08 C2 42 01 00 00 00 00 
{142} normal block at 0x00414E58, 8 bytes long.
 Data: <$ B     > 24 C5 42 01 00 00 00 00 
{141} normal block at 0x00414E10, 8 bytes long.
 Data: <  B     > E4 C4 42 01 00 00 00 00 
{140} normal block at 0x00414DC8, 8 bytes long.
 Data: <  B     > 04 C5 42 01 00 00 00 00 
{139} normal block at 0x00414D80, 8 bytes long.
 Data: <  B     > C4 C4 42 01 00 00 00 00 
{138} normal block at 0x00414D38, 8 bytes long.
 Data: <H B     > 48 C5 42 01 00 00 00 00 
Object dump complete.
The program '[6188] LeakCheck.exe: Native' has exited with code 0 (0x0).

Original comment by pkoh...@gmail.com on 18 Dec 2011 at 8:26

[GoogleCodeExporter]

The new code still leak.

==1052== 35 bytes in 1 blocks are possibly lost in loss record 7 of 24
==1052==    at 0x4A22557: operator new(unsigned long) (vg_replace_malloc.c:298)
==1052==    by 0x539A900: std::string::_Rep::_S_create(unsigned long, unsigned 
long, std::allocator<char> const&) (new_allocator.h:92)
==1052==    by 0x539B2C4: char* std::string::_S_construct<char const*>(char 
const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) 
(basic_string.tcc:144)
==1052==    by 0x539B402: std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) 
(basic_string.h:1465)
==1052==    by 0x4C474EA: google::(anonymous 
namespace)::LogFileObject::LogFileObject(int, char const*) (logging.cc:632)
==1052==    by 0x4C47598: google::LogDestination::LogDestination(int, char 
const*) (logging.cc:400)
==1052==    by 0x4C4BA43: google::LogMessage::SendToLog() (logging.cc:607)
==1052==    by 0x4C4AC17: google::LogMessage::Flush() (logging.cc:1102)
==1052==    by 0x4C4AE48: google::LogMessage::~LogMessage() (logging.cc:1069)
==1052==    by 0x40399E: main (main.cpp:104)

Original comment by zhangpei...@gmail.com on 12 Oct 2012 at 10:16

[GoogleCodeExporter]

The following code layout under VS2008-2012 will eliminate falsely reported 
memory leaks.

int main(int argc, char * argv[])
{
#if defined(_WIN32) && !defined(NDEBUG)
    // These global strings in GLOG are initially reserved with a small
    // amount of storage space (16 bytes). Resizing the string larger than its
    // initial size, after the _CrtMemCheckpoint call, can be reported as
    // a memory leak.
    // So for 'debug builds', where memory leak checking is performed,
    // reserve a large enough space so the string will not be resized later.
    // For these variables, _MAX_PATH should be fine.
    FLAGS_log_dir.reserve(_MAX_PATH);  // comment out this line to trigger false memory leak
    FLAGS_log_link.reserve(_MAX_PATH);

    // Enable memory dump from within VS.
    _CrtMemState memState;
    _CrtMemCheckpoint(&memState);
#endif

    {
        // This call needs to be done after _CrtMemCheckpoint. If not then VS2008 reports
        // 2 memory leaks, and VS2012 reports 6 memory leaks.
        google::InitGoogleLogging(argv[0]);

        // This could trigger a false memory leak if the string
        // was not resized prior to the memState snapshot.
        FLAGS_log_dir = "C:\\Some\\Valid\\Directory\\were\\the\\string\\length\\is\\greater\\than\\16";

        LOG(INFO) << "log it";

        google::ShutdownGoogleLogging();
    }
#if defined(_WIN32) && !defined(NDEBUG)
    // Check for memory leaks in debug builds.
    _CrtMemDumpAllObjectsSince(&memState);
#endif
    return 0;
}

Original comment by pkoh...@gmail.com on 17 Jan 2013 at 2:52