Valgrind将其检测为可能的内存泄漏

Question

Below is the extract of Code, in which i am getting some 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 is the error what i am getting from Valgrind

==4594== 
==4594== 67 bytes in 1 blocks are possibly lost in loss record 754 of 1,141
==4594==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==4594==    by 0x5812CA8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104)
==4594==    by 0x581387A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629)
==4594==    by 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510)
==4594==    by 0x58139B7: std::string::append(std::string const&) (basic_string.tcc:332)
==4594==    by 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==    by 0x45ED5F: pbsc::PBSCAppMain(int, char**) (PBSCApp.cpp:686)
==4594==    by 0x45EC9B: main (PBSCApp.cpp:677)
==4594== 

My Question is when control leave this function why still memory is associated to this function? I am calling this function number of times that's why my program size keeps on growing.

Please suggest where exactly i am doing mistake.

Adding one more extract from Valgrind report that shows that even control return from the function but still memory taken freed.

==4594== 4,620 bytes in 110 blocks are possibly lost in loss record 1,092 of 1,141
==4594==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==4594==    by 0x5812CA8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104)
==4594==    by 0x581387A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629)
==4594==    by 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510)
==4594==    by 0x5087CA2: log4cxx::helpers::Transcoder::decode(std::string const&, std::string&) (transcoder.cpp:248)
==4594==    by 0x503FA1A: log4cxx::LogManager::getLogger(std::string const&) (logmanager.cpp:120)
==4594==    by 0x503A498: log4cxx::Logger::getLogger(std::string const&) (logger.cpp:490)
==4594==    by 0x4204D0: FIELD_UT::InitializeLogger(unsigned int, int) (FIELD_UT.cpp:19)
==4594==    by 0x415074: BeamM::FIELD_UT(unsigned int, int, int, int&) (Beam.cpp:62)
==4594==    by 0x4158E0: BeamM::OnUplinkLlcPdu(rgw::pbscpmc::PMC-PBSC-MetaMessage const&, int&) (BeamM.cpp:134)
==4594==    by 0x425551: PBSC_SYS::OnUplinkLlcPdu(rgw::pbscpmc::PMC_PBSC_MetaMessage const&) (PBSC_SYS.cpp:135)
==4594==    by 0x4136A2: PBSCAppMain::HandleMessage(unsigned short, char const*, int) (PBSCAppMain.cpp:28)

I can't post all the code but can elaborate the sequence, hope i will be able to make it....

1. As shown in Valgrind report, PBSCAppMain() after receiving something on socket call, PBSC_SYS::OnUplinkLlcPdu.
2. PBSC_SYS::OnUplinkLlcPdu calls BeamM::OnUplinkLlcPdu.
3. BeamM::OnUplinkLlcPdu creates object for FIELD_UT.

4. from BeamM::OnUplinkLlcPdu, FIELD_UT::InitializeLogger is called to initialize its logger. Here is the exact code line for 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 i am not wrong, after initilizing Logger control will be back then why in that case also, valgring says...Possibly leak.

Thanks..

Answer 1

it stays in while 1, continously keeps on checking data on socket and also keep reading the files

Well if it stays in the loop forever (or, rather, until the process is forcibly terminated), then (within the context of the program) control never leaves the function.

So when did you expect these resources to be freed? Valgrind doesn't know either.

This is a false positive; don't worry about it.
(Notice that it says "possibly lost", not "definitely lost".)

Answer 2

try changing

char pbscPath[255];
std::string configDir = "/../config/";
std::string pbscBinPath = getcwd(pbscPath,255);
std::string pbscConfigPath = pbscBinPath + configDir;

to

char pbscConfigPath[300];
getcwd(pbscConfigPath,255);
strcat(pbscConfigPath,"/../config/");

Old school but you don't have to worry about hidden class stuff, (and it's faster too).