valgrind reports that tcmalloc from gperftools-2.4 leaks some memory #758

Open
shlomif opened this Issue Jan 14, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@shlomif

shlomif commented Jan 14, 2016

Hi all,

with a simple test.c file , valgrind-3.11.0-4.mga6 reports that there are leaks. (on Mageia Linux x86-64 v6 and lib64google-perftools-devel-2.4-1.mga6 ):

shlomif[fcs]:$trunk/fc-solve/build$ cat test.c
#include <stdlib.h>

int main()
{
    void * buffer = malloc(100);
    free (buffer);

    return 0;
}
shlomif[fcs]:$trunk/fc-solve/build$ gcc -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free test.c -ltcmalloc
shlomif[fcs]:$trunk/fc-solve/build$ valgrind --leak-check=full --show-leak-kinds=all ./a.out 

The valgrind output is:

==16766== Memcheck, a memory error detector
==16766== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16766== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==16766== Command: ./a.out
==16766== 
==16766== 
==16766== HEAP SUMMARY:
==16766==     in use at exit: 72,744 bytes in 3 blocks
==16766==   total heap usage: 15 allocs, 12 frees, 74,550 bytes allocated
==16766== 
==16766== 8 bytes in 1 blocks are still reachable in loss record 1 of 3
==16766==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16766==    by 0x4E5EE0D: ??? (in /usr/lib64/libtcmalloc.so.4.2.6)
==16766==    by 0x4E4A67C: ??? (in /usr/lib64/libtcmalloc.so.4.2.6)
==16766==    by 0x400F0C9: call_init.part.0 (in /usr/lib64/ld-2.22.so)
==16766==    by 0x400F1DA: _dl_init (in /usr/lib64/ld-2.22.so)
==16766==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==16766== 
==16766== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==16766==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16766==    by 0x4E4A5DB: ??? (in /usr/lib64/libtcmalloc.so.4.2.6)
==16766==    by 0x400F0C9: call_init.part.0 (in /usr/lib64/ld-2.22.so)
==16766==    by 0x400F1DA: _dl_init (in /usr/lib64/ld-2.22.so)
==16766==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==16766== 
==16766== 72,704 bytes in 1 blocks are still reachable in loss record 3 of 3
==16766==    at 0x4C28076: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16766==    by 0x57021FF: pool (eh_alloc.cc:117)
==16766==    by 0x57021FF: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==16766==    by 0x57021FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==16766==    by 0x400F0C9: call_init.part.0 (in /usr/lib64/ld-2.22.so)
==16766==    by 0x400F1DA: _dl_init (in /usr/lib64/ld-2.22.so)
==16766==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==16766== 
==16766== LEAK SUMMARY:
==16766==    definitely lost: 0 bytes in 0 blocks
==16766==    indirectly lost: 0 bytes in 0 blocks
==16766==      possibly lost: 0 bytes in 0 blocks
==16766==    still reachable: 72,744 bytes in 3 blocks
==16766==         suppressed: 0 bytes in 0 blocks
==16766== 
==16766== For counts of detected and suppressed errors, rerun with: -v
==16766== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
shlomif[fcs]:$trunk/fc-solve/build$ 

Please look into fixing it.

@alk

This comment has been minimized.

Show comment
Hide comment
@alk

alk Jan 25, 2016

Contributor

I'm not able to reproduce this problem on my debian unstable system. Neither on 2.4 tag nor on current master branch.

Contributor

alk commented Jan 25, 2016

I'm not able to reproduce this problem on my debian unstable system. Neither on 2.4 tag nor on current master branch.

@shlomif

This comment has been minimized.

Show comment
Hide comment
@shlomif

shlomif Jan 25, 2016

Thanks for the info, @alk! I have now tried to reproduce it with the current master branch of tcmalloc built from source on Mageia Linux x86-64 v6 and I am still getting the same report from valgrind. For the record:

shlomif@telaviv1:~$ rpm -q gcc
gcc-5.3.1-0.20160112.1.mga6
shlomif@telaviv1:~$ rpm -q gcc-c++
gcc-c++-5.3.1-0.20160112.1.mga6
shlomif@telaviv1:~$ rpm -qf /usr/include/c++/5.3.1/array 
libstdc++-devel-5.3.1-0.20160112.1.mga6

Perhaps it's a problem with this version of gcc.

shlomif commented Jan 25, 2016

Thanks for the info, @alk! I have now tried to reproduce it with the current master branch of tcmalloc built from source on Mageia Linux x86-64 v6 and I am still getting the same report from valgrind. For the record:

shlomif@telaviv1:~$ rpm -q gcc
gcc-5.3.1-0.20160112.1.mga6
shlomif@telaviv1:~$ rpm -q gcc-c++
gcc-c++-5.3.1-0.20160112.1.mga6
shlomif@telaviv1:~$ rpm -qf /usr/include/c++/5.3.1/array 
libstdc++-devel-5.3.1-0.20160112.1.mga6

Perhaps it's a problem with this version of gcc.

@pterjan

This comment has been minimized.

Show comment
Hide comment
@pterjan

pterjan Jan 25, 2016

With debuginfo:

==33471== 8 bytes in 1 blocks are still reachable in loss record 1 of 3
==33471==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x4E5EE0D: InitModule() [clone .part.7] (malloc_extension.cc:204)
==33471==    by 0x4E4A67C: UnknownInlinedFun (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: google_init_module_malloc_extension_init (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: UnknownInlinedFun (googleinit.h:46)
==33471==    by 0x4E4A67C: UnknownInlinedFun (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: _GLOBAL__sub_I_malloc_extension.cc (malloc_extension.cc:378)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==33471== 
==33471== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==33471==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x4E4A5DB: UnknownInlinedFun (symbolize.cc:75)
==33471==    by 0x4E4A5DB: _GLOBAL__sub_I_symbolize.cc (symbolize.cc:285)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==33471== 
==33471== 72,704 bytes in 1 blocks are still reachable in loss record 3 of 3
==33471==    at 0x4C28076: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x57021FF: pool (eh_alloc.cc:117)
==33471==    by 0x57021FF: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==33471==    by 0x57021FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)

First one malloc_extension.cc:204 is current_instance = new MallocExtension in:

static void InitModule() {
  if (current_instance != NULL) {
    return;
  }
  current_instance = new MallocExtension;
#ifndef NO_HEAP_CHECK
  HeapLeakChecker::IgnoreObject(current_instance);
#endif
}

Second one symbolize.cc:75 is:

static string* g_pprof_path = new string(FLAGS_symbolize_pprof);

Third one is from gcc code.

pterjan commented Jan 25, 2016

With debuginfo:

==33471== 8 bytes in 1 blocks are still reachable in loss record 1 of 3
==33471==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x4E5EE0D: InitModule() [clone .part.7] (malloc_extension.cc:204)
==33471==    by 0x4E4A67C: UnknownInlinedFun (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: google_init_module_malloc_extension_init (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: UnknownInlinedFun (googleinit.h:46)
==33471==    by 0x4E4A67C: UnknownInlinedFun (malloc_extension.cc:210)
==33471==    by 0x4E4A67C: _GLOBAL__sub_I_malloc_extension.cc (malloc_extension.cc:378)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==33471== 
==33471== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==33471==    at 0x4C28696: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x4E4A5DB: UnknownInlinedFun (symbolize.cc:75)
==33471==    by 0x4E4A5DB: _GLOBAL__sub_I_symbolize.cc (symbolize.cc:285)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)
==33471== 
==33471== 72,704 bytes in 1 blocks are still reachable in loss record 3 of 3
==33471==    at 0x4C28076: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==33471==    by 0x57021FF: pool (eh_alloc.cc:117)
==33471==    by 0x57021FF: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==33471==    by 0x57021FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==33471==    by 0x400F0C9: call_init.part.0 (dl-init.c:72)
==33471==    by 0x400F1DA: call_init (dl-init.c:30)
==33471==    by 0x400F1DA: _dl_init (dl-init.c:120)
==33471==    by 0x4000C89: ??? (in /usr/lib64/ld-2.22.so)

First one malloc_extension.cc:204 is current_instance = new MallocExtension in:

static void InitModule() {
  if (current_instance != NULL) {
    return;
  }
  current_instance = new MallocExtension;
#ifndef NO_HEAP_CHECK
  HeapLeakChecker::IgnoreObject(current_instance);
#endif
}

Second one symbolize.cc:75 is:

static string* g_pprof_path = new string(FLAGS_symbolize_pprof);

Third one is from gcc code.

@alk

This comment has been minimized.

Show comment
Hide comment
@alk

alk Jan 27, 2016

Contributor

Those two places leak newed objects intentionally. And I'm not sure why valgrind on my box is ok with that and yours isn't.

Contributor

alk commented Jan 27, 2016

Those two places leak newed objects intentionally. And I'm not sure why valgrind on my box is ok with that and yours isn't.

@shlomif

This comment has been minimized.

Show comment
Hide comment
@shlomif

shlomif Jan 27, 2016

@alk: are there any suppressions defined there for libtcmalloc?

shlomif commented Jan 27, 2016

@alk: are there any suppressions defined there for libtcmalloc?

@alk

This comment has been minimized.

Show comment
Hide comment
@alk

alk Jan 30, 2016

Contributor

I'm not seeing any tcmalloc-related supressions

Contributor

alk commented Jan 30, 2016

I'm not seeing any tcmalloc-related supressions

@shlomif

This comment has been minimized.

Show comment
Hide comment
@shlomif

shlomif Jan 30, 2016

On Fri, 29 Jan 2016 23:45:07 -0800
"Aliaksey Kandratsenka (aka Aliaksei Kandratsenka)" notifications@github.com
wrote:

I'm not seeing any tcmalloc-related supressions

I see . How strange!

shlomif commented Jan 30, 2016

On Fri, 29 Jan 2016 23:45:07 -0800
"Aliaksey Kandratsenka (aka Aliaksei Kandratsenka)" notifications@github.com
wrote:

I'm not seeing any tcmalloc-related supressions

I see . How strange!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment