Re: [Valgrind-developers] VALGRIND_DO_LEAK_CHECK false positives

[Sergei T. <sl...@in...>]

Resending to val...@li...

On Tue, 25 Mar 2008 12:00:28 +0100
Julian Seward <js...@ac...> wrote:

> 
> > I've tried to insert VALGRIND_DO_LEAK_CHECK into program's main
> > loop, but eventually got false positive `definetly lost' blocks in
> > this place (there's no memleaks when program normally stops in
> > valgrind's report).
> >
> > The question is:
> > Does VALGRIND_DO_LEAK_CHECK work in ANY cases and I
> > should model this situation and report a bug, or there is yet some
> > cases memcheck can't handle?
> 
> False positives are possible, but unlikely.  The probability of a
> false positive increases as the address space gets more and more
> used, which is probably why you saw them.
> 
> Anyway.  It sounds like you maybe need to use Valgrind's Massif
> tool to find the cause of the allocations (--tool=massif).  Make
> sure to use Massif in Valgrind version 3.3.0.  Some documentation
> is here:
> 
> http://www.valgrind.org/docs/manual/ms-manual.html
> 
> J
> 
Thanks!

I think massif wouldn't help me much. Traced program takes much
time (2-3 weeks under memcheck) to run and crashes (VM runout). So, I'd
like to see any detectable leaks ASAP.

I still cannot reproduce `definetly lost' fp, but have annoying
`possibly lost' messages:

// source:
$ cat main.cc 
#include <string>

#include <valgrind/memcheck.h>

int main ()
{
    std::string s("hello");
    VALGRIND_DO_LEAK_CHECK;
    return 0;
}

// built by: g++ -g -O0    -c -o main.o main.cc
// result (current svn):
$ valgrind ./vg_ml_test 
...
==11287== 
==11287== searching for pointers to 1 not-freed blocks.
==11287== checked 106,228 bytes.
==11287== 
==11287== 18 bytes in 1 blocks are possibly lost in loss record 1 of 1
==11287==    at 0x4021FF4: operator new(unsigned)
(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==11287==    by 0x40C69EF: std::string::_Rep::_S_create(unsigned,
unsigned, std::allocator<char> const&)
(in /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6.0.9)
==11287==    by 0x40C7CF4:
(within /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6.0.9)
==11287==    by 0x40C7EA6: std::string::string(char const*,
std::allocator<char> const&)
(in /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6.0.9)
==11287==    by 0x804859A: main (main.cc:9)
==11287== ==11287== LEAK
SUMMARY:
==11287==    definitely lost: 0 bytes in 0 blocks.
==11287==      possibly lost: 18 bytes in 1 blocks.
==11287==    still
reachable: 0 bytes in 0 blocks.
==11287==         suppressed: 0 bytes
in 0 blocks.
==11287==
==11287== ERROR SUMMARY: 0 errors from 0
contexts (suppressed: 7 from 1)
==11287== malloc/free: in use at exit:
0 bytes in 0 blocks.
==11287== malloc/free: 1 allocs, 1 frees, 18 bytes
allocated.
==11287== For counts of detected errors, rerun with: -v
==11287== All heap blocks were freed -- no leaks are possible.

Is it possible to write simple suppression for this case, just fix it,
or it's not an error and I should write valgrind-wrapped custom
allocator?

Thanks!