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....

  1. as shown in valgrind report, pbscappmain() after receiving on socket call, pbsc_sys::onuplinkllcpdu.
  2. pbsc_sys::onuplinkllcpdu calls beamm::onuplinkllcpdu.
  3. beamm::onuplinkllcpdu creates object field_ut.
  4. 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

Popular posts from this blog

Java 3D LWJGL collision -

spring - SubProtocolWebSocketHandler - No handlers -

methods - python can't use function in submodule -