Valgrind 将此检测为可能的内存泄漏答案

【问题标题】：Valgrind detect this as Possible Memory LeakValgrind 将此检测为可能的内存泄漏
【发布时间】：2015-08-12 17:59:54
【问题描述】：

以下是代码的摘录，其中我在 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 创建对象。
来自 BeamM::OnUplinkLlcPdu，调用 FIELD_UT::InitializeLogger 来初始化其记录器。这是确切的代码行。

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

void UT::InitializeLogger(unsigned int tlli, int beamId) { mLLogger = log4cxx::Logger::getLogger("ut." + to_string(lli)); LOG4CXX_DEBUG(mLogger, "UT Logger 创建"); }

现在如果我没记错的话，在初始化 Logger 控制之后会回来，那么为什么在这种情况下，valgring 说...可能泄漏。

谢谢..

【问题讨论】：

如果你注释掉那些函数调用会发生什么？
对我来说似乎是误报。也许pbsc::PBSCAppMain 调用exit？没有 testcase 就无法判断。
看起来它正在分配内存来添加两个字符串，然后它没有被释放。
“何时控制离开此功能” 什么时候发生？
@Verma：那么，如果它永远停留在循环中（或者，更确切地说，直到进程被强制终止），那么（在程序的上下文中）控制 never 离开功能。那么您预计何时释放这些资源？ Valgrind 也不知道。这是误报；别担心。（注意它是如何说“可能丢失”，而不是“肯定丢失”。）下次请出示 testcase（按照如何提问指南中的要求），以便我们可以立即知道这种细节。

标签： c++ c++11 memory-leaks valgrind

【解决方案1】：

尝试改变

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

老派，但您不必担心隐藏的课程内容，（而且速度也更快）。

【讨论】：

为什么要降价？这可以解决问题并提供快速有效的解决方案，而不会出现内存错误。

【解决方案2】：

它停留在while 1中，不断检查socket上的数据并继续读取文件

如果它永远停留在循环中（或者，更确切地说，直到进程被强制终止），那么（在程序的上下文中）控制永远离开函数。

那么您预计这些资源何时会被释放？ Valgrind 也不知道。

这是误报；不用担心。
（注意它说的是“可能丢失”，而不是“肯定丢失”。）

【讨论】：