Bug #3747
closed
Fix memory leak associated with logger
0%
Description
While running valgrind on NLSR to test another patch, I discovered a memory leak:
==7279== 16 bytes in 1 blocks are still reachable in loss record 82 of 1,103
==7279== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7279== by 0x66566F1: log4cxx::pattern::NameAbbreviator::getDefaultAbbreviator() (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x6657B9B: log4cxx::pattern::NamePatternConverter::getAbbreviator(std::vector<std::string, std::allocator<std::string> > const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x6657C0C: log4cxx::pattern::NamePatternConverter::NamePatternConverter(std::string const&, std::string const&, std::vector<std::string, std::allocator<std::string> > const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x66463CF: log4cxx::pattern::LoggerPatternConverter::LoggerPatternConverter(std::vector<std::string, std::allocator<std::string> > const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x66465D7: log4cxx::pattern::LoggerPatternConverter::newInstance(std::vector<std::string, std::allocator<std::string> > const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x6666950: log4cxx::pattern::PatternParser::createConverter(std::string const&, std::string&, std::map<std::string, log4cxx::helpers::ObjectPtrT<log4cxx::pattern::PatternConverter> (*)(std::vector<std::string,
std::allocator<std::string> > const&), std::less<std::string>, std::allocator<std::pair<std::string const, log4cxx::helpers::ObjectPtrT<log4cxx::pattern::PatternConverter> (*)(std::vector<std::string, std::allocator<std::stri
ng> > const&)> > > const&, std::vector<std::string, std::allocator<std::string> >&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x6666FAF: log4cxx::pattern::PatternParser::finalizeConverter(char, std::string const&, int, std::string&, log4cxx::helpers::ObjectPtrT<log4cxx::pattern::FormattingInfo> const&, std::map<std::string, log4cxx::h
elpers::ObjectPtrT<log4cxx::pattern::PatternConverter> (*)(std::vector<std::string, std::allocator<std::string> > const&), std::less<std::string>, std::allocator<std::pair<std::string const, log4cxx::helpers::ObjectPtrT<log4c
xx::pattern::PatternConverter> (*)(std::vector<std::string, std::allocator<std::string> > const&)> > > const&, std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::PatternConverter>, std::allocator<log4cxx::helpers::Obj
ectPtrT<log4cxx::pattern::PatternConverter> > >&, std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::FormattingInfo>, std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::FormattingInfo> > >&) (in /usr/lib/li
blog4cxx.so.10.0.0)
==7279== by 0x666823C: log4cxx::pattern::PatternParser::parse(std::string const&, std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::PatternConverter>, std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::
PatternConverter> > >&, std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::FormattingInfo>, std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::pattern::FormattingInfo> > >&, std::map<std::string, log4cxx::helpers::O
bjectPtrT<log4cxx::pattern::PatternConverter> (*)(std::vector<std::string, std::allocator<std::string> > const&), std::less<std::string>, std::allocator<std::pair<std::string const, log4cxx::helpers::ObjectPtrT<log4cxx::patte
rn::PatternConverter> (*)(std::vector<std::string, std::allocator<std::string> > const&)> > > const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x6662FEF: log4cxx::PatternLayout::activateOptions(log4cxx::helpers::Pool&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x666346D: log4cxx::PatternLayout::PatternLayout(std::string const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==7279== by 0x4571A7: INIT_LOGGERS(std::string const&, std::string const&) (logger.cpp:58)
==7279== by 0x46BD59: nlsr::NlsrRunner::run() (nlsr-runner.cpp:53)
==7279== by 0x42A76D: main (main.cpp:58)
Ashlesh identified the offending file to be src/logger.cpp. I suggest changing this to a shared_ptr, which manages itself and will automatically deallocate itself when it goes out of scope.
Updated by Alex Afanasyev about 8 years ago
How exactly do you run valgrind to get this output?
Updated by Nicholas Gordon about 8 years ago
I used mini-ndn on a 2-node topology with the pingall test. I replaced the call to NLSR in mini-ndn with this line:
NdnApplication.start(self, "valgrind --tool=memcheck --leak-check=yes --leak-resolution=high --num-callers=40 --show-leak-kinds=all /home/nmg/nlsr-commented/build/bin/nlsr -d -f {} 2&>{}/valgrindlog &".format(self.confFile, self.logDir))
I also tested it by adding nlsr-log-level="NONE" to each node in the topology file as suggested by Ashlesh, but it had no apparent effect.
Updated by Nicholas Gordon about 8 years ago
After getting around to this and looking through the code, I have come to think that perhaps valgrind was being extra-cautious for me. It looks as though that the loggers can only be initialized once. As a result, this bug may be a non-issue.
Updated by Nicholas Gordon about 8 years ago
- Status changed from New to Rejected
During the poking around phase of this issue, we realized that valgrind is indeed reporting a vaild leak, but it looks like this is a case of "let program termination handle this one". The function is an initialization function, and during the function call it sets a flag that prevents future initialization of this same function. Further, no other functions change this flag, so we can be sure that this is not an accumulating problem. So, this is a non-issue and will closed.