I have a problem with a memory leak and the output of Valgrind:
==4501== 15,263,488 bytes in 59,623 blocks are definitely lost in loss record 5,941 of 5,942
==4501== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4501== by 0x6CC78D1: newlocale (newlocale.c:201)
==4501== by 0x527EE7: app::TLocale::create(app::ELocale) (locale.cpp:141)
==4501== by 0x5276AD: app::TLocale::TLocale() (locale.cpp:38)
==4501== by 0x50091E: util::TDateTime::TDateTime(util::EDateTimeType) (datetime.cpp:828)
==4501== by 0x587EE4: util::TVariant::TVariant() (variant.cpp:74)
==4501== by 0x561215: data::TField::TField() (tables.cpp:193)
==4501== by 0x554EA7: sqlite::TQuery::assignFields() (sqlite.cpp:631)
==4501== by 0x553C80: sqlite::TQuery::next() (sqlite.cpp:415)
==4501== by 0x4F8E06: sql::TDataQuery::fetchAll() (database.cpp:219)
==4501== by 0x5CD499: app::TMain::qryPersonalData(std::string&, unsigned long, unsigned long, std::string const&, unsigned long) (main.cpp:1616)
==4501== by 0x5CCF86: app::TMain::getPersonalData(app::TThreadData&, char const*&, unsigned long&, util::TNamedVariants&) (main.cpp:1568)
If i look at the first lines I would asume that newlocale() is used without freelocale(). But I checked the code again and again, this is not the case.
Am I misinterpreting the output and the leakage might be somewhere else?
From the traceback it's not that obvious that pairing of newlocale and freelocale is the culprit. There's a number of constructors (TLocale, TDateTime, TVariant and TField) that would probably have to be destroyed as well (if the freelocale is called from the destructor). You should check that there is no memory leaks of those classes as well (for example if you have a new TLocale without delete you would get another memory leak detected).
More than that is hard to tell without seeing enough of the source code.
Related
In my project i am using jsoncpp, boost and many libraries, when i ran the valgrind for my program in many palces including jsoncpp, boost libraries it shows possible memory leak in string creation
I have pasted the valgrind error snippets
==5506== 427,198 bytes in 489 blocks are possibly lost in loss record 8,343 of 8,359
==5506== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5506== by 0x9360A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==5506== by 0x55EB0BD: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:140)
==5506== by 0x936261C: std::basic_string, std::allocator >::basic_string(char
const*, unsigned long, std::allocator const&) (in
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==5506== by 0x63FEB99: Json::Value::asString() const (json_value.cpp:611)
My question is are these errors are valid or they are false positive ?
Thanks in advance
To be completely sure, you can do a looped test and check for memory hogging.
We had similar messages and they turned out to be false positives, so we added them to the suppression list.
Valgrind has some heuristics that reduces the number of 'false positive'
possibly lost.
A.o., it has an heuristic to better detect std::string.
Use the following options to activate some heuristics:
--leak-check-heuristics=heur1,heur2,... which heuristics to use for
improving leak search false positive [none]
where heur is one of:
stdstring length64 newarray multipleinheritance all none
Note that in the upcoming 3.11 release, the default for this option
has been changed from 'none' to 'all'.
I'm seeing a truly baffling series of error reports from Valgrind's Memcheck tool:
==29456== Invalid read of size 8
==29456== at 0x4D5C90: CkIndex_Ping1::_callthr_trecv_PingMsg(CkThrCallArg*) (in /scratch/phil/charm/net-linux-x86_64-bigsim/tests/charm++/pingpong/pgm)
==29456== by 0x503ECB: CthStartThread (libthreads-default.c:1690)
==29456== by 0x56A08AF: ??? (in /lib/x86_64-linux-gnu/libc-2.19.so)
==29456== Address 0x5b09a90 is 0 bytes inside a block of size 16 alloc'd
==29456== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29456== by 0x4D5C14: CkIndex_Ping1::_call_trecv_PingMsg(void*, void*) (in /scratch/phil/charm/net-linux-x86_64-bigsim/tests/charm++/pingpong/pgm)
==29456== by 0x517D79: CkDeliverMessageFree (ck.C:593)
==29456== by 0x5378C3: CkLocRec_local::invokeEntry(CkMigratable*, void*, int, bool) (cklocation.C:1795)
==29456== by 0x537CA7: CkLocRec_local::deliver(CkArrayMessage*, CkDeliver_t, int) (cklocation.C:1862)
==29456== by 0x539977: CkLocMgr::deliver(CkMessage*, CkDeliver_t, int) (cklocation.C:2834)
==29456== by 0x51F091: CkLocMgr::deliverInline(CkMessage*) (cklocation.h:313)
==29456== by 0x51A6EF: _processArrayEltMsg(CkCoreState*, envelope*) (ck.C:1181)
==29456== by 0x51A8C8: _processHandler(void*, CkCoreState*) (ck.C:1266)
==29456== by 0x4EE7EF: BgProcessMessageDefault(threadInfo*, char*) (blue.C:1339)
==29456== by 0x5C5928: BgProcessMessageFreezeMode(threadInfo*, char*) (middle-ccs.C:165)
==29456== by 0x4F590D: workThreadInfo::scheduler(int) (bigsim_proc.C:282)
Note that it's saying that the offending address is inside a still-allocated (i.e. not yet free()'d) block, and that the read size plus offset is well less than the size of the block.
This is on Ubuntu Linux 14.04, with Valgrind version valgrind-3.10.0.SVN (package 1:3.10~20140411-0ubuntu1), and the code was compiled with gcc/g++ 4.8.4-2ubuntu1~14.04.
I've found a similar question, to which the answer was "this is a bug on Mac OS X". Am I really looking at a Valgrind bug here, or is there something else my code might have wrong?
Edit: I also found a mailing list post covering a similar environment - user-level threads that might be screwing with Valgrind's understanding. It doesn't seem to actually answer anything though.
I have been digging several days in my 1500 lines of code to find those 15 bytes (possibly lost) to no avail.
There are no sufficient data provided by valgrind even though I ran the following command:
valgrind --leak-check=full --show-reachable=yes --track-origins=yes --show-below-main=yes ./myapp
I get the following block of report:
==3283== 15 bytes in 1 blocks are possibly lost in loss record 1 of 4
==3283== at 0x402842F: operator new(unsigned int) (vg_replace_malloc.c:255)
==3283== by 0x40D2A83: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==3283== by 0x40D4CF7: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==3283== by 0x40D4E65: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==3283== by 0x804DB22: _GLOBAL__sub_I__ZN7processC2Ei7in_addr (main.cpp:1304)
==3283== by 0x8050131: __libc_csu_init (in /home/username/myapp-write/src/myapp)
==3283== by 0x41A60A9: __libc_start_main (libc-start.c:185)
==3283== by 0x80499C0: ??? (in /home/username/myapp-write/src/myapp)
==3283==
Would any one, please, tell me how to detect the faulty line?
If your code invokes alternative termination strategies that are not designed to properly clean up automatic variables due to hindering unwind semantics, your automatic variable destructors will not be called.
std::terminate, as you mentioned in-comment you were using, unfortunately ponies up one such condition. The default action for the termination handler is to invoke std::abort, which does not fire cleanup destruction on automatic, thread-local, or static storage duration objects, and any such vars that have assumed dynamic memory management will leak like a sieve.
Avoid termination in this fashion unless you have a very good reason for it, and in general there are very few good reasons for it.
Best of luck.
Very new to c++ but got my hands on valgrind that I played with during the day. Got my code cleaned up nicely, except from a part that uses an external library (xqilla). What I can see there is both a memory leak and error. Does this mean I should look at a different library or is it common that libraries has errors and small leaks that I shouldn't care about it?
Valgrind output
==8779== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s)
==8779== at 0x6065829: sendmmsg (sendmmsg.c:32)
==8779== by 0x767C8FD: __libc_res_nsend (res_send.c:1140)
==8779== by 0x7679D48: __libc_res_nquery (res_query.c:226)
==8779== by 0x767A6F8: __libc_res_nsearch (res_query.c:582)
==8779== by 0x746CB57: _nss_dns_gethostbyname4_r (dns-host.c:314)
==8779== by 0x6035ADF: gaih_inet (getaddrinfo.c:849)
==8779== by 0x6039913: getaddrinfo (getaddrinfo.c:2473)
==8779== by 0x50B3F06: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== Address 0x7feffdad0 is on thread 1's stack
==8779==
Hello
Good
Bye
==8779==
==8779== HEAP SUMMARY:
==8779== in use at exit: 11 bytes in 1 blocks
==8779== total heap usage: 8,144 allocs, 8,143 frees, 1,957,496 bytes allocated
==8779==
==8779== 11 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8779== at 0x4C2A879: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8779== by 0x4FEC508: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B87D5: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3C6D: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE0D03: xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50053B8: xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5008931: xercesc_3_1::XMLScanner::scanDocument(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5027474: xercesc_3_1::AbstractDOMParser::parse(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==
==8779== LEAK SUMMARY:
==8779== definitely lost: 11 bytes in 1 blocks
==8779== indirectly lost: 0 bytes in 0 blocks
==8779== possibly lost: 0 bytes in 0 blocks
==8779== still reachable: 0 bytes in 0 blocks
==8779== suppressed: 0 bytes in 0 blocks
==8779==
==8779== For counts of detected and suppressed errors, rerun with: -v
==8779== Use --track-origins=yes to see where uninitialised values come from
==8779== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 2 from 2)
If the library is indeed leaking memory, it would be wise to resolve it as the leak could eventually impact the application. Typical symptoms of a memory leak include a hung process, or a process that terminates abruptly (such as when the Linux out-of-memory killer goes to work).
Looking for another library may be viable. If the library maintainers can be reached, it would be good to bring it to their attention. And, if it is open source, it would be even more awesome to track it down and submit a fix.
One thing to consider here though. Valgrind is going to flag any memory that is not eventually released as a leak. The library may be making one-time allocations, such as creating singletons. If that's the case, then it is really a non-problem.
So, things to try:
Track down what interactions with the library create the leaks
Confirm that those interactions actually leak - meaning that they make more than one allocation over time
Check the library for operations that may clean up the memory
Verify the use of the library (for example, make sure a cleanup method/function that should be called is being called)
Contact the maintainers
Track it down and fix it (if it's opensource)
The errors referring to the pointers to uninitialized bytes does not necessarily mean anything is wrong, just that the library has allocated pointers and not set the allocated memory to any value. If the program runs into segmentation faults, those errors could be helpful to track them down. Otherwise, it could be totally normal. For example, the library may be pre-allocating buffers for later use.
Again, I would consider mentioning them to maintainers, but those errors by themselves are not too worrisome.
The output format is displaying stack so its hard to find the root cause.
==21663== Invalid read of size 4
==21663== at 0x4448117: iurcall_init_rlmgt_IsAllAlcapSuccess(Iurcall_Init_CallCtx_t*) (iurcall_init_rlmgt_p.cc:6319)
==21663== by 0x47D98DD: iurcall_init_rlmgt_IsAllAlcapSuccess_Test_return_1_when_edchMacD_flow_ctx_not_exist_and_alcapEstablish_is_FALSE_Test::TestBody() (iurcall_init_rlmgt_p_test.cc:373)
==21663== by 0x8BCAB27: testing::Test::Run() (gmock-gtest-all.cc:3436)
==21663== by 0x8BD1966: testing::internal::TestInfoImpl::Run() (gmock-gtest-all.cc:3655)
==21663== by 0x8BD1AA8: testing::TestCase::Run() (gmock-gtest-all.cc:3761)
==21663== by 0x8BD1D96: testing::internal::UnitTestImpl::RunAllTests() (gmock-gtest-all.cc:5365)
==21663== by 0x8BD1F21: testing::UnitTest::Run() (gmock-gtest-all.cc:5028)
==21663== by 0x4820149: Gtest_initialisation(int, char**) (iurcall_init_gtest_main.cc:49)
==21663== by 0x808E500: main (bosinit_config_template.h:439)
==21663== Address 0xa8190e4 is 44 bytes inside a block of size 56 free'd
This Valgrind output looks incomplete. It should be something like in this question where the second call stack is printed after Address 0xa8190e4 is 44 bytes inside a block of size 56 free'd.
This call stack is the root cause of the problem. It is not a memory leak. You are trying to work with already deallocated object. The second call stack is where the object was deallocated and the first one is where it was used.