|
From: Sergei T. <sl...@in...> - 2008-03-24 19:34:46
|
Hello! I extensively use valgrind --tool=memcheck. And once upon a time I've got long running program merely consuming memory (just leaky), so valgrind dies of OOM. 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? Thanks! |
|
From: Julian S. <js...@ac...> - 2008-03-25 11:04:32
|
> 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 |
|
From: Sergei T. <sl...@in...> - 2008-03-30 18:05:58
|
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! |
|
From: Sergei T. <sl...@in...> - 2008-04-12 07:26:10
|
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.
Got FP samle for memcheck + VALGRIND_DO_LEAK_CHECK
Sample source and valgrind's logs are in attach.
Program models the way how std::string (and possibly std::map) works in
GNU STL (gcc-4.2.3).
// pseudocode:
typedef char * my_string;
my_string mk_str() {
char * p = new char[1024];
return p + 10;
}
void del_str(my_string s) {
delete [] (s-10);
}
> 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
>
I tried massif for my real program. Massif SIGSEGVed at program shutdown
(https://bugs.kde.org/show_bug.cgi?id=160736). I'll try to write a
sample to model my program.
Can this situation be fixed in memcheck (changing definitely lost to
possibly lost would be sufficient in sample source)?
Thanks!
|