Question

以下是Code的摘录，其中我在Valgrind报告中获得了一些可能的记忆丧失。

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)

我无法发布所有代码，但可以详细说明序列，希望我能够做到....

如Valgrind报告所示，PBSCAppMain（）收到套接字调用后的内容，PBSC_SYS :: OnUplinkLlcPdu。
PBSC_SYS :: OnUplinkLlcPdu调用BeamM :: OnUplinkLlcPdu。
BeamM :: OnUplinkLlcPdu为FIELD_UT创建对象。
，调用FIELD_UT :: InitializeLogger来初始化其记录器。这是确切的代码行。

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

void UT :: InitializeLogger（unsigned int tlli，int beamId） { mLogger = log4cxx :: Logger :: getLogger（“ut。”+ to_string（lli））; LOG4CXX_DEBUG（mLogger，“UT Logger created”）; }

现在，如果我没有错，在启动Logger控制后将会回来，那么为什么在那种情况下，valgring说...可能泄漏。

谢谢..

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/");

老派，但你不必担心隐藏的课堂内容（而且它也更快）。

Valgrind将此视为可能的内存泄漏

2 个答案: