|
From: John R. <jr...@bi...> - 2014-12-07 19:40:54
|
> I ran valgrind to check a fairly large open source software, and found a number of memory leak issues. But I am not sure if those leaks are issues in valgrind or the tested software. I list part of the error messages below: > > 20 bytes in 2 blocks are definitely lost in loss record 12 of 53 > at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so > > by 0x6113AB1: strdup (strdup.c 43) > by 0x476767: tpltlex() (in /usr/sbin/xorpsh) > by 0x471EA8: tpltparse (in /usr/sbin/xorpsh) > by 0x47281B: parse_template() (in /usr/sbin/xorpsh) > by 0x45D446: TemplateTree::parse_file (std::string const& , std::string const&, std::string&) (in /usr/sbin/xorpsh) > by 0x45E9A4: TemplateTree::load_template_tree(std::string const& , std::string&) (in /usr/sbin/xorpsh) > by 0x425BAB: XorpShell::XorpShell(EventLoop&, std::string const&, std::string const&, std::string const&, bool) (in /usr/sbin/xorpsh) > by 0x426293: main(in /usr/sbin/xorpsh) > > > The loss is in a valgrind file, The malloc() subroutine which performed the allocation is the memcheck function which intercepts the call to the malloc that is contained in libc. All memory leaks will show some memcheck intercepting function as the allocator of the leaked block. That is the way that memcheck starts tracking the allocated blocks. but in the tested software, even though the lost is caused by a number of functions and methods in the tested software. Yes, the tested software forgot to call free() for this particular block. How to interpret this? Thank you very much. |