This patch forces leak_cpp_interior to be compiled using old implementation
of std::string.
Related issue #373069
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16217
It looks like the standard says that
#define __STDC_FORMAT_MACROS
is needed in c++ in order to have PRIxPTR defined.
At least on gcc110 g++ 4.7.2, leak_cpp_interior.cpp
was not compiling.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15435
pointing at offset 64bit of a block, when the first 8 bytes contains
the block size - 8. This is e.g. used by sqlite3MemMalloc.
Patch by Matthias Schwarzott (with small modif)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14179
* fix the assert
* some better comments
* update test to verify who_points_at behaviour with an interiorly pointed block
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13609
Depending on the compiler or optimisation level, the blocks that
are supposed to be possibly leaked are still reachable.
=> change the pointers to be global variables,
and do the allocation in a function, not in main.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13591
The option --leak-check-heuristics=heur1,heur2,... can activate
various heuristics to decrease the number of false positive
"possible leaks" for C++ code. The available heuristics are
detecting valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers pointing
to an inner part of a C++ object using multiple inheritance.
This fixes 280271 Valgrind reports possible memory leaks on still-reachable
std::string
This has been tested on x86/amd64/ppc32/ppc64.
First performance measurements seems to show a neglectible impact on
the leak search.
More feedback welcome both on performance and functional aspects
(false positive 'possibly leaked' rate decrease and/or
false negative 'possibly leaked' rate increase).
Note that the heuristic is not checking that the memory has been
allocated with "new" or "new[]", as it is expected that in some cases,
specific alloc fn are used for c++ objects instead of the standard new/new[].
If needed, we might add an option to check the alloc functions
to be new/new[].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13582
