Valgrind false-positive Mismatched free() / delete / delete [] with tcmalloc 2.5 #792
Description
Using valgrind on a program linked with tcmalloc works with the --soname-synonyms=somalloc=*tcmalloc* valgrind option.
However, starting with tcmalloc 2.5 I have a false positive Mismatched free() / delete / delete [] with the following code:
int main(int argc, char **argv)
{
int* i = new int;
delete i;
return 0;
}$ g++ -o bug bug.cpp -ltcmalloc_minimal
$ valgrind --tool=memcheck --soname-synonyms=somalloc=*tcmalloc* ./bug
==15874== Memcheck, a memory error detector
==15874== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==15874== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==15874== Command: ./bug
==15874==
==15874== Mismatched free() / delete / delete []
==15874== at 0x4C2BE9C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15874== by 0x400795: main (in bug)
==15874== Address 0x5c671e0 is 0 bytes inside a block of size 4 alloc'd
==15874== at 0x4C2B9E0: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15874== by 0x400785: main (in bug)
==15874==
==15874==
==15874== HEAP SUMMARY:
==15874== in use at exit: 46 bytes in 3 blocks
==15874== total heap usage: 6 allocs, 3 frees, 52 bytes allocated
==15874==
==15874== LEAK SUMMARY:
==15874== definitely lost: 0 bytes in 0 blocks
==15874== indirectly lost: 0 bytes in 0 blocks
==15874== possibly lost: 30 bytes in 1 blocks
==15874== still reachable: 16 bytes in 2 blocks
==15874== suppressed: 0 bytes in 0 blocks
==15874== Rerun with --leak-check=full to see details of leaked memory
==15874==
==15874== For counts of detected and suppressed errors, rerun with: -v
==15874== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)It works correctly with tcmalloc 2.4:
$ valgrind --tool=memcheck --soname-synonyms=somalloc=*tcmalloc* ./bug-tcmalloc-2.4
==16288== Memcheck, a memory error detector
==16288== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==16288== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==16288== Command: ./bug-tcmalloc-2.4
==16288==
==16288==
==16288== HEAP SUMMARY:
==16288== in use at exit: 46 bytes in 3 blocks
==16288== total heap usage: 6 allocs, 3 frees, 52 bytes allocated
==16288==
==16288== LEAK SUMMARY:
==16288== definitely lost: 0 bytes in 0 blocks
==16288== indirectly lost: 0 bytes in 0 blocks
==16288== possibly lost: 30 bytes in 1 blocks
==16288== still reachable: 16 bytes in 2 blocks
==16288== suppressed: 0 bytes in 0 blocks
==16288== Rerun with --leak-check=full to see details of leaked memory
==16288==
==16288== For counts of detected and suppressed errors, rerun with: -v
==16288== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It also works correctly without tcmalloc.
I reproduced the issue with tcmalloc 2.5 and master, valgrind 3.10.0 and 3.11.0, on redhat-7 and ubuntu-14.04.
I don't know if it's an issue with tcmalloc, or with valgrind, or both, so I'll stick with tcmalloc 2.4 for now.