valgrind reports that tcmalloc from gperftools-2.4 leaks some memory
Author: shlomifCreated Jan 14, 2016Updated Jan 12, 2026
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.
Source: gperftools/gperftools