Valgrind將其檢測為可能的內存泄漏

Question

下面是代碼的摘錄，其中我在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

以下是我從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== 

我的問題是，當控件離開此功能時，為何仍將內存與該功能關聯？ 我多次調用此函數，這就是我的程序大小不斷增長的原因。

請指出我到底在哪里做錯。

從Valgrind報告中再添加一個摘要，該摘要顯示即使該控件返回了該函數，但仍釋放了內存。

==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)

我不能發布所有代碼，但是可以詳細說明序列，希望我能夠做到。

1. 如Valgrind報告中所示，PBSCAppMain（）在套接字調用PBSC_SYS :: OnUplinkLlcPdu上收到內容后。
2. PBSC_SYS :: OnUplinkLlcPdu調用BeamM :: OnUplinkLlcPdu。
3. BeamM :: OnUplinkLlcPdu為FIELD_UT創建對象。

4. 從BeamM :: OnUplinkLlcPdu中調用FIELD_UT :: InitializeLogger來初始化其記錄器。 這是確切的代碼行。

   void BeamM :: UpdateUT（）{shared_ptr pUt = nullptr; pUt = AddUT（lli）; pUt-> InitializeLogger（lli）; }

   無效UT :: InitializeLogger（unsigned int tlli，int beamId）{mLogger = log4cxx :: Logger :: getLogger（“ ut。” + to_string（lli））; LOG4CXX_DEBUG（mLogger，“已創建UT Logger”）; }

現在，如果我沒有記錯的話，在初始化Logger控件后又會回來，那為什么在這種情況下，也會顯示錯誤消息...可能是泄漏。

謝謝..

Answer 1

它停留在1的同時，繼續檢查套接字上的數據，並繼續讀取文件

好吧，如果它永遠停留在循環中（或者，直到該過程被強制終止），那么（在程序的上下文中）控制就永遠不會離開函數。

那么，您何時期望釋放這些資源？ Valgrind也不知道。

這是一個假陽性； 不用擔心
（請注意，它說的是“可能丟失”，而不是“絕對丟失”。）

Answer 2

嘗試改變

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

至

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

老派，但您不必擔心隱藏的課程（而且速度也更快）。