|
From: Peng Yu <pen...@gm...> - 2011-09-07 06:17:12
|
Hi,
valgrind reports that there is possible lost. But it doesn't seem
there should be any lost. Why valgrind reports it as possible lost? Is
there a way to remove such 'possible lost' from the valgrind report?
/tmp$ cat main.cpp
#include <stdexcept>
int main() {
throw std::runtime_error("xx");
}
/tmp$ g++ main.cpp
/tmp$ valgrind ./a.out
==32312== Memcheck, a memory error detector
==32312== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32312== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==32312== Command: ./a.out
==32312==
--32312-- ./a.out:
--32312-- dSYM directory is missing; consider using --dsymutil=yes
terminate called after throwing an instance of 'std::runtime_error'
what(): xx
==32312==
==32312== Process terminating with default action of signal 6 (SIGABRT)
==32312== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib)
==32312== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler()
(in /usr/lib/libstdc++.6.0.9.dylib)
==32312== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in
/usr/lib/libstdc++.6.0.9.dylib)
==32312== by 0x10006DB15: std::terminate() (in
/usr/lib/libstdc++.6.0.9.dylib)
==32312== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib)
==32312== by 0x100000DF7: main (in ./a.out)
==32312==
==32312== HEAP SUMMARY:
==32312== in use at exit: 259 bytes in 4 blocks
==32312== total heap usage: 5 allocs, 1 frees, 282 bytes allocated
==32312==
==32312== LEAK SUMMARY:
==32312== definitely lost: 0 bytes in 0 blocks
==32312== indirectly lost: 0 bytes in 0 blocks
==32312== possibly lost: 27 bytes in 1 blocks
==32312== still reachable: 232 bytes in 3 blocks
==32312== suppressed: 0 bytes in 0 blocks
==32312== Rerun with --leak-check=full to see details of leaked memory
==32312==
==32312== For counts of detected and suppressed errors, rerun with: -v
==32312== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Abort trap
--
Regards,
Peng
|
|
From: Jeffrey W. <nol...@gm...> - 2011-09-07 06:31:40
|
Hi Peng, On Wed, Sep 7, 2011 at 2:17 AM, Peng Yu <pen...@gm...> wrote: > Hi, > > valgrind reports that there is possible lost. But it doesn't seem > there should be any lost. Why valgrind reports it as possible lost? Is > there a way to remove such 'possible lost' from the valgrind report? I've found I'll get the same reports when using global objects. If you are using global objects, put them in an accessor function. In an accessor, the dtors will run, and you won't violate C++'s rule on non-local statics (and cross module dependencies). If you are not using globals, then accept my apologies. Jeff |
|
From: Peng Yu <pen...@gm...> - 2011-09-07 06:44:36
|
On Wed, Sep 7, 2011 at 1:31 AM, Jeffrey Walton <nol...@gm...> wrote: > Hi Peng, > > On Wed, Sep 7, 2011 at 2:17 AM, Peng Yu <pen...@gm...> wrote: >> Hi, >> >> valgrind reports that there is possible lost. But it doesn't seem >> there should be any lost. Why valgrind reports it as possible lost? Is >> there a way to remove such 'possible lost' from the valgrind report? > I've found I'll get the same reports when using global objects. > > If you are using global objects, put them in an accessor function. In > an accessor, the dtors will run, and you won't violate C++'s rule on > non-local statics (and cross module dependencies). I don't exactly following your instructions. Would you please show me an concrete example on how to change my simple test code? Thanks! -- Regards, Peng |
|
From: Tom H. <to...@co...> - 2011-09-07 07:43:01
|
On 07/09/11 07:17, Peng Yu wrote: > valgrind reports that there is possible lost. But it doesn't seem > there should be any lost. Why valgrind reports it as possible lost? Is > there a way to remove such 'possible lost' from the valgrind report? Well if you do what it says and use "-leak-check=full" then you might find out where the leak is coming from. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peng Yu <pen...@gm...> - 2011-09-07 13:07:38
|
On Wed, Sep 7, 2011 at 2:42 AM, Tom Hughes <to...@co...> wrote: > On 07/09/11 07:17, Peng Yu wrote: > >> valgrind reports that there is possible lost. But it doesn't seem >> there should be any lost. Why valgrind reports it as possible lost? Is >> there a way to remove such 'possible lost' from the valgrind report? > > Well if you do what it says and use "-leak-check=full" then you might find > out where the leak is coming from. Here is the output with "-leak-check=full". How can I tell that there is definitely no memory leak? /tmp$ valgrind --leak-check=full ./a.out ==40738== Memcheck, a memory error detector ==40738== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==40738== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==40738== Command: ./a.out ==40738== --40738-- ./a.out: --40738-- dSYM directory is missing; consider using --dsymutil=yes terminate called after throwing an instance of 'std::runtime_error' what(): xx ==40738== ==40738== Process terminating with default action of signal 6 (SIGABRT) ==40738== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib) ==40738== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x10006DB15: std::terminate() (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x100000DF7: main (in ./a.out) ==40738== ==40738== HEAP SUMMARY: ==40738== in use at exit: 259 bytes in 4 blocks ==40738== total heap usage: 5 allocs, 1 frees, 282 bytes allocated ==40738== ==40738== 27 bytes in 1 blocks are possibly lost in loss record 2 of 4 ==40738== at 0x100010D7B: operator new(unsigned long) (vg_replace_malloc.c:261) ==40738== by 0x1000534D0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x10005517C: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x10005555E: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738== by 0x100000D55: main (in ./a.out) ==40738== ==40738== LEAK SUMMARY: ==40738== definitely lost: 0 bytes in 0 blocks ==40738== indirectly lost: 0 bytes in 0 blocks ==40738== possibly lost: 27 bytes in 1 blocks ==40738== still reachable: 232 bytes in 3 blocks ==40738== suppressed: 0 bytes in 0 blocks ==40738== Reachable blocks (those to which a pointer was found) are not shown. ==40738== To see them, rerun with: --leak-check=full --show-reachable=yes ==40738== ==40738== For counts of detected and suppressed errors, rerun with: -v ==40738== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Abort trap -- Regards, Peng |
|
From: Dan K. <da...@ke...> - 2011-09-07 13:45:38
|
After a SIGABRT, wouldn't you expect a bunch of memory leaks? Or if you just want to get rid of the possibly lost messages, try --show-possibly-lost=no On Wed, Sep 7, 2011 at 6:07 AM, Peng Yu <pen...@gm...> wrote: > On Wed, Sep 7, 2011 at 2:42 AM, Tom Hughes <to...@co...> wrote: >> On 07/09/11 07:17, Peng Yu wrote: >> >>> valgrind reports that there is possible lost. But it doesn't seem >>> there should be any lost. Why valgrind reports it as possible lost? Is >>> there a way to remove such 'possible lost' from the valgrind report? >> >> Well if you do what it says and use "-leak-check=full" then you might find >> out where the leak is coming from. > > Here is the output with "-leak-check=full". How can I tell that there > is definitely no memory leak? > > > /tmp$ valgrind --leak-check=full ./a.out > ==40738== Memcheck, a memory error detector > ==40738== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==40738== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==40738== Command: ./a.out > ==40738== > --40738-- ./a.out: > --40738-- dSYM directory is missing; consider using --dsymutil=yes > terminate called after throwing an instance of 'std::runtime_error' > what(): xx > ==40738== > ==40738== Process terminating with default action of signal 6 (SIGABRT) > ==40738== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib) > ==40738== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler() > (in /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in > /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x10006DB15: std::terminate() (in > /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x100000DF7: main (in ./a.out) > ==40738== > ==40738== HEAP SUMMARY: > ==40738== in use at exit: 259 bytes in 4 blocks > ==40738== total heap usage: 5 allocs, 1 frees, 282 bytes allocated > ==40738== > ==40738== 27 bytes in 1 blocks are possibly lost in loss record 2 of 4 > ==40738== at 0x100010D7B: operator new(unsigned long) > (vg_replace_malloc.c:261) > ==40738== by 0x1000534D0: std::string::_Rep::_S_create(unsigned > long, unsigned long, std::allocator<char> const&) (in > /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x10005517C: char* std::string::_S_construct<char > const*>(char const*, char const*, std::allocator<char> const&, > std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x10005555E: std::basic_string<char, > std::char_traits<char>, std::allocator<char> >::basic_string(char > const*, std::allocator<char> const&) (in > /usr/lib/libstdc++.6.0.9.dylib) > ==40738== by 0x100000D55: main (in ./a.out) > ==40738== > ==40738== LEAK SUMMARY: > ==40738== definitely lost: 0 bytes in 0 blocks > ==40738== indirectly lost: 0 bytes in 0 blocks > ==40738== possibly lost: 27 bytes in 1 blocks > ==40738== still reachable: 232 bytes in 3 blocks > ==40738== suppressed: 0 bytes in 0 blocks > ==40738== Reachable blocks (those to which a pointer was found) are not shown. > ==40738== To see them, rerun with: --leak-check=full --show-reachable=yes > ==40738== > ==40738== For counts of detected and suppressed errors, rerun with: -v > ==40738== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > Abort trap > > > > -- > Regards, > Peng > > ------------------------------------------------------------------------------ > Using storage to extend the benefits of virtualization and iSCSI > Virtualization increases hardware utilization and delivers a new level of > agility. Learn what those decisions are and how to modernize your storage > and backup environments for virtualization. > http://www.accelacomm.com/jaw/sfnl/114/51434361/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Peng Yu <pen...@gm...> - 2011-09-07 14:37:43
|
On Wed, Sep 7, 2011 at 8:45 AM, Dan Kegel <da...@ke...> wrote:
> After a SIGABRT, wouldn't you expect a bunch of memory leaks?
So, basically, you are saying I can ignore all the possibly lost after
SIGABRT, right?
I think that there is problem between std::string and valgrind. I
changed the the std:string used inside std::runtime_error and get a
new class ValgrindRuntimeError. Using this new class, the possibly
lost is gone.
#include <stdexcept>
#include <iostream>
#include <vector>
class ValgrindRuntimeError : public std::exception {
public:
/** Takes a character string describing the error. */
ValgrindRuntimeError(char s[]) {
_s=new char[strlen(s)];
strcpy(_s, s);
}
virtual ~ValgrindRuntimeError() throw() {
delete[] _s;
}
/** Returns a C-style character string describing the general cause of
* the current error (the same string passed to the ctor). */
virtual const char* what() const throw() {
return _s;
}
private:
char *_s;
};
int main() {
ValgrindRuntimeError a(std::string("xxxx").c_str());
throw a;
}
> Or if you just want to get rid of the possibly lost messages, try
> --show-possibly-lost=no
I'm afraid that I miss some true lost using this option.
> On Wed, Sep 7, 2011 at 6:07 AM, Peng Yu <pen...@gm...> wrote:
>> On Wed, Sep 7, 2011 at 2:42 AM, Tom Hughes <to...@co...> wrote:
>>> On 07/09/11 07:17, Peng Yu wrote:
>>>
>>>> valgrind reports that there is possible lost. But it doesn't seem
>>>> there should be any lost. Why valgrind reports it as possible lost? Is
>>>> there a way to remove such 'possible lost' from the valgrind report?
>>>
>>> Well if you do what it says and use "-leak-check=full" then you might find
>>> out where the leak is coming from.
>>
>> Here is the output with "-leak-check=full". How can I tell that there
>> is definitely no memory leak?
>>
>>
>> /tmp$ valgrind --leak-check=full ./a.out
>> ==40738== Memcheck, a memory error detector
>> ==40738== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
>> ==40738== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
>> ==40738== Command: ./a.out
>> ==40738==
>> --40738-- ./a.out:
>> --40738-- dSYM directory is missing; consider using --dsymutil=yes
>> terminate called after throwing an instance of 'std::runtime_error'
>> what(): xx
>> ==40738==
>> ==40738== Process terminating with default action of signal 6 (SIGABRT)
>> ==40738== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib)
>> ==40738== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler()
>> (in /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in
>> /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x10006DB15: std::terminate() (in
>> /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x100000DF7: main (in ./a.out)
>> ==40738==
>> ==40738== HEAP SUMMARY:
>> ==40738== in use at exit: 259 bytes in 4 blocks
>> ==40738== total heap usage: 5 allocs, 1 frees, 282 bytes allocated
>> ==40738==
>> ==40738== 27 bytes in 1 blocks are possibly lost in loss record 2 of 4
>> ==40738== at 0x100010D7B: operator new(unsigned long)
>> (vg_replace_malloc.c:261)
>> ==40738== by 0x1000534D0: std::string::_Rep::_S_create(unsigned
>> long, unsigned long, std::allocator<char> const&) (in
>> /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x10005517C: char* std::string::_S_construct<char
>> const*>(char const*, char const*, std::allocator<char> const&,
>> std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x10005555E: std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >::basic_string(char
>> const*, std::allocator<char> const&) (in
>> /usr/lib/libstdc++.6.0.9.dylib)
>> ==40738== by 0x100000D55: main (in ./a.out)
>> ==40738==
>> ==40738== LEAK SUMMARY:
>> ==40738== definitely lost: 0 bytes in 0 blocks
>> ==40738== indirectly lost: 0 bytes in 0 blocks
>> ==40738== possibly lost: 27 bytes in 1 blocks
>> ==40738== still reachable: 232 bytes in 3 blocks
>> ==40738== suppressed: 0 bytes in 0 blocks
>> ==40738== Reachable blocks (those to which a pointer was found) are not shown.
>> ==40738== To see them, rerun with: --leak-check=full --show-reachable=yes
>> ==40738==
>> ==40738== For counts of detected and suppressed errors, rerun with: -v
>> ==40738== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>> Abort trap
>>
>>
>>
>> --
>> Regards,
>> Peng
>>
>> ------------------------------------------------------------------------------
>> Using storage to extend the benefits of virtualization and iSCSI
>> Virtualization increases hardware utilization and delivers a new level of
>> agility. Learn what those decisions are and how to modernize your storage
>> and backup environments for virtualization.
>> http://www.accelacomm.com/jaw/sfnl/114/51434361/
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
--
Regards,
Peng
|
|
From: Tom H. <to...@co...> - 2011-09-07 14:39:44
|
On 07/09/11 15:37, Peng Yu wrote: > I think that there is problem between std::string and valgrind. I > changed the the std:string used inside std::runtime_error and get a > new class ValgrindRuntimeError. Using this new class, the possibly > lost is gone. Please read the FAQ entry about std::string and memory leaks: http://valgrind.org/docs/manual/faq.html#faq.reports Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peng Yu <pen...@gm...> - 2011-09-07 14:53:41
|
On Wed, Sep 7, 2011 at 9:39 AM, Tom Hughes <to...@co...> wrote: > On 07/09/11 15:37, Peng Yu wrote: > >> I think that there is problem between std::string and valgrind. I >> changed the the std:string used inside std::runtime_error and get a >> new class ValgrindRuntimeError. Using this new class, the possibly >> lost is gone. > > Please read the FAQ entry about std::string and memory leaks: > > http://valgrind.org/docs/manual/faq.html#faq.reports Using malloc, doesn't help in this case. See below. /tmp$ cat main.cpp #include <stdexcept> int main() { throw std::runtime_error("xx"); } /tmp$ g++ --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /tmp$ export GLIBCXX_FORCE_NEW /tmp$ g++ main.cpp /tmp$ valgrind ./a.out ==42321== Memcheck, a memory error detector ==42321== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==42321== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==42321== Command: ./a.out ==42321== --42321-- ./a.out: --42321-- dSYM directory is missing; consider using --dsymutil=yes terminate called after throwing an instance of 'std::runtime_error' what(): xx ==42321== ==42321== Process terminating with default action of signal 6 (SIGABRT) ==42321== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib) ==42321== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/libstdc++.6.0.9.dylib) ==42321== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in /usr/lib/libstdc++.6.0.9.dylib) ==42321== by 0x10006DB15: std::terminate() (in /usr/lib/libstdc++.6.0.9.dylib) ==42321== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib) ==42321== by 0x100000DF7: main (in ./a.out) ==42321== ==42321== HEAP SUMMARY: ==42321== in use at exit: 259 bytes in 4 blocks ==42321== total heap usage: 5 allocs, 1 frees, 282 bytes allocated ==42321== ==42321== LEAK SUMMARY: ==42321== definitely lost: 0 bytes in 0 blocks ==42321== indirectly lost: 0 bytes in 0 blocks ==42321== possibly lost: 27 bytes in 1 blocks ==42321== still reachable: 232 bytes in 3 blocks ==42321== suppressed: 0 bytes in 0 blocks ==42321== Rerun with --leak-check=full to see details of leaked memory ==42321== ==42321== For counts of detected and suppressed errors, rerun with: -v ==42321== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Abort trap -- Regards, Peng |