Project

General

Profile

Bug #3236

PriorityFifoPolicy memory leak

Added by Junxiao Shi almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
High
Category:
Tables
Target version:
Start date:
10/03/2015
Due date:
% Done:

100%

Estimated time:

Description

nfd::cs::priority_fifo::PriorityFifoPolicy::attachQueue has a memory leak.

Steps to reproduce:

  1. start NFD in valgrind with --leak-check=full, wait for initialization procedure to complete
  2. start ndnpingserver /A
  3. start ndnping -i 10 /A, wait 5 minutes
  4. stop NFD by CTRL+C

Valgrind reports:

==12466== 1,963,504 (857,344 direct, 1,106,160 indirect) bytes in 26,792 blocks are definitely lost in loss record 379 of 379
==12466==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12466==    by 0x4C4E1A: nfd::cs::priority_fifo::PriorityFifoPolicy::attachQueue(std::_Rb_tree_const_iterator<nfd::cs::EntryImpl>) (cs-policy-priority-fifo.cpp:104)
==12466==    by 0x4C512A: nfd::cs::priority_fifo::PriorityFifoPolicy::doAfterInsert(std::_Rb_tree_const_iterator<nfd::cs::EntryImpl>) (cs-policy-priority-fifo.cpp:44)
==12466==    by 0x4C5E41: nfd::cs::Policy::afterInsert(std::_Rb_tree_const_iterator<nfd::cs::EntryImpl>) (cs-policy.cpp:54)
==12466==    by 0x4C6823: nfd::cs::Cs::insert(ndn::Data const&, bool) (cs.cpp:113)
==12466==    by 0x48C131: nfd::Forwarder::onIncomingData(nfd::Face&, ndn::Data const&) (forwarder.cpp:395)
==12466==    by 0x48C66C: nfd::Forwarder::startProcessData(nfd::Face&, ndn::Data const&) (forwarder.cpp:79)
==12466==    by 0x488214: std::_Function_handler<void (ndn::Data const&), std::_Bind<std::_Mem_fn<void (nfd::Forwarder::*)(nfd::Face&, ndn::Data const&)> (nfd::Forwarder*, std::reference_wrapper<nfd::Face>, std::_Placeholder<1>)> >::_M_invoke(std::_Any_data const&, ndn::Data const&) (functional:601)
==12466==    by 0x449BD5: std::function<void (ndn::Data const&)>::operator()(ndn::Data const&) const (functional:2471)
==12466==    by 0x4542BD: ndn::util::signal::Signal<nfd::Face, ndn::Data>::operator()(ndn::Data const&) (signal-signal.hpp:241)
==12466==    by 0x452F16: nfd::face::LpFaceWrapper::dispatchData(ndn::Data const&) (signal-signal.hpp:255)
==12466==    by 0x454467: std::_Function_handler<void (ndn::Data const&), std::_Bind<std::_Mem_fn<void (nfd::face::LpFaceWrapper::*)(ndn::Data const&)> (nfd::face::LpFaceWrapper*, std::_Placeholder<1>)> >::_M_invoke(std::_Any_data const&, ndn::Data const&) (functional:601)

PriorityFifoPolicy::attachQueue allocates an EntryInfo object with new operator, but the PriorityFifoPolicy never deallocates this object with the delete operator or through smart pointers.


Files

nfd.valgrind.log (143 KB) nfd.valgrind.log Junxiao Shi, 10/03/2015 12:10 PM

Related issues

Related to NFD - Bug #3222: NFD performance degradation over time using NDN-RTCRejected09/23/2015

Actions
#1

Updated by Junxiao Shi almost 5 years ago

  • Related to Bug #3222: NFD performance degradation over time using NDN-RTC added
#2

Updated by Junxiao Shi almost 5 years ago

This is assigned to Minsheng, author of PriorityFifoPolicy class.

I'm attaching the full valgrind report.
It shows several other memory leaks, but these are only "1 block" so I'm not concerned.

#3

Updated by Minsheng Zhang almost 5 years ago

  • % Done changed from 0 to 70
#4

Updated by Minsheng Zhang almost 5 years ago

  • Status changed from New to Code review
#5

Updated by Minsheng Zhang almost 5 years ago

  • Status changed from Code review to Closed
  • % Done changed from 70 to 100
#6

Updated by Junxiao Shi almost 5 years ago

the implementation should have been changed to use unique_ptr, if possible

gcc46's std::map does not support noncopyable mapped type such as unique_ptr.

Changing to std::unordered_map is not an option because logic needs an ordered container.

Also available in: Atom PDF