c++ - Valgrind detect this as Possible Memory Leak -
below extract of code, in getting possible memory loss in valgrind report.
681 int pbsc::pbscappmain( int argc, char **argv ) 682 { 683 char pbscpath[255]; 684 std::string configdir = "/../config/"; 685 std::string pbscbinpath = getcwd(pbscpath,255); 686 std::string pbscconfigpath = pbscbinpath + configdir; 687 688 689 690 std::string localconfigfile = pbsc::getfilenamefromdir(pbscconfigpath, pbsc_local_config_file); 691 if(false == localconfigfile.empty()) 692 { 693 std::string localconfigfilewithpath = pbscconfigpath + localconfigfile; 694 readlocalconfiguration(localconfigfilewithpath); 695 } 696 697 std::string loggerconfigfile = pbsc::getfilenamefromdir(pbscconfigpath, pbsc_logger_config_file); 698 if(false == loggerconfigfile.empty()) 699 { 700 std::string loggerconfigfilewithpath = pbscconfigpath + loggerconfigfile; 701 log4cxx::propertyconfigurator::configureandwatch(loggerconfigfilewithpath, 20000); 702 } 703
below error getting valgrind
==4594== ==4594== 67 bytes in 1 blocks possibly lost in loss record 754 of 1,141 ==4594== @ 0x4a075bc: operator new(unsigned long) (vg_replace_malloc.c:298) ==4594== 0x5812ca8: std::string::_rep::_s_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104) ==4594== 0x581387a: std::string::_rep::_m_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629) ==4594== 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510) ==4594== 0x58139b7: std::string::append(std::string const&) (basic_string.tcc:332) ==4594== 0x455446: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:2369) ==4594== 0x45ed5f: pbsc::pbscappmain(int, char**) (pbscapp.cpp:686) ==4594== 0x45ec9b: main (pbscapp.cpp:677) ==4594==
my question when control leave function why still memory associated function? calling function number of times that's why program size keeps on growing.
please suggest doing mistake.
adding 1 more extract valgrind report shows control return function still memory taken freed.
==4594== 4,620 bytes in 110 blocks possibly lost in loss record 1,092 of 1,141 ==4594== @ 0x4a075bc: operator new(unsigned long) (vg_replace_malloc.c:298) ==4594== 0x5812ca8: std::string::_rep::_s_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104) ==4594== 0x581387a: std::string::_rep::_m_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629) ==4594== 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510) ==4594== 0x5087ca2: log4cxx::helpers::transcoder::decode(std::string const&, std::string&) (transcoder.cpp:248) ==4594== 0x503fa1a: log4cxx::logmanager::getlogger(std::string const&) (logmanager.cpp:120) ==4594== 0x503a498: log4cxx::logger::getlogger(std::string const&) (logger.cpp:490) ==4594== 0x4204d0: field_ut::initializelogger(unsigned int, int) (field_ut.cpp:19) ==4594== 0x415074: beamm::field_ut(unsigned int, int, int, int&) (beam.cpp:62) ==4594== 0x4158e0: beamm::onuplinkllcpdu(rgw::pbscpmc::pmc-pbsc-metamessage const&, int&) (beamm.cpp:134) ==4594== 0x425551: pbsc_sys::onuplinkllcpdu(rgw::pbscpmc::pmc_pbsc_metamessage const&) (pbsc_sys.cpp:135) ==4594== 0x4136a2: pbscappmain::handlemessage(unsigned short, char const*, int) (pbscappmain.cpp:28)
i can't post code can elaborate sequence, hope able make it....
- as shown in valgrind report, pbscappmain() after receiving on socket call, pbsc_sys::onuplinkllcpdu.
- pbsc_sys::onuplinkllcpdu calls beamm::onuplinkllcpdu.
- beamm::onuplinkllcpdu creates object field_ut.
from beamm::onuplinkllcpdu, field_ut::initializelogger called initialize logger. here exact code line that.
void beamm::updateut() { shared_ptr put = nullptr; put = addut(lli); put->initializelogger(lli); }
void ut::initializelogger(unsigned int tlli, int beamid) { mlogger = log4cxx::logger::getlogger("ut." + to_string(lli)); log4cxx_debug(mlogger, "ut logger created"); }
now if not wrong, after initilizing logger control why in case also, valgring says...possibly leak.
thanks..
it stays in while 1, continously keeps on checking data on socket , keep reading files
well if stays in loop forever (or, rather, until process forcibly terminated), (within context of program) control never leaves function.
so when did expect these resources freed? valgrind doesn't know either.
this false positive; don't worry it.
(notice says "possibly lost", not "definitely lost".)
Comments
Post a Comment