[ndnSIM] High Memory Usage & Potential Memory Leaks

Wed Feb 18 10:48:15 PST 2015

Hello Christian,

I created a redmine issue for that in order to figure out what is going on:

http://redmine.named-data.net/issues/2538

Thank you

--
Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/
Internet Research Laboratory
PhD Computer Science
UCLA

> On Feb 18, 2015, at 1:02 AM, Christian Kreuzberger <christian.kreuzberger at itec.aau.at> wrote:
> 
> Hi,
>  
> using the latest version of ndnSIM and ndn-cxx, I’ve noticed a rather high memory usage (several gigabytes, with
> content store set to 1 packet) in simulations involving plenty of interests and data packets. So I’ve compiled ndnSIM 
> in debug mode and started the ndn-simple example (from scratch directory) with valgrind active, here is the 
> summary of the output.
>  
> ./waf --command-template="valgrind --leak-check=full --show-reachable=yes %s" --run ndn-simple
>  
>  
> ==9678== 1,738,712 (408 direct, 1,738,304 indirect) bytes in 3 blocks are definitely lost in loss record 448 of 448
> ==9678==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==9678==    by 0x5AD027F: ns3::Ptr<ns3::Node> ns3::CreateObject<ns3::Node>() (object.h:423)
> ==9678==    by 0xD9C8CFA: ns3::NodeContainer::Create(unsigned int) (node-container.cc:137)
> ==9678==    by 0x41C856: ns3::main(int, char**) (ndn-simple.cc:63)
> ==9678==    by 0x41D2D7: main (ndn-simple.cc:107)
> ==9678== 
> ==9678== LEAK SUMMARY:
> ==9678==    definitely lost: 408 bytes in 3 blocks
> ==9678==    indirectly lost: 1,738,304 bytes in 8,257 blocks
> ==9678==      possibly lost: 98 bytes in 3 blocks
> ==9678==    still reachable: 656 bytes in 33 blocks
> ==9678==         suppressed: 0 bytes in 0 blocks
>  
>  
> At first, this looks like that the memory lost is only when creating a node, which is not good, but would be “okay” for 
> simulations. But when you dig deeper into the generated output of valgrind, you will find that the problem is caused
> by several allocations about packets, regular expressions, skiplists in content store, etc… I’m not an expert in that field, 
> but I thought it is worth mentioning on the mailing list.
> Example of the most important ones:
>  
> ==9806== 238,400 bytes in 200 blocks are indirectly lost in loss record 447 of 448
> ==9806==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==9806==    by 0x8DE20A2: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<ndn::Data, std::allocator<ndn::Data>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) (new_allocator.h:104)
> ==9806==    by 0x8DE1D3D: std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<ndn::Data, std::allocator<ndn::Data>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<ndn::Data, std::allocator<ndn::Data>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) (alloc_traits.h:351)
> ==9806==    by 0x8DE18E7: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<ndn::Data, std::allocator<ndn::Data>>(std::_Sp_make_shared_tag, ndn::Data*, std::allocator<ndn::Data> const&) (shared_ptr_base.h:499)
> ==9806==    by 0x8DE138D: std::__shared_ptr<ndn::Data, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<ndn::Data>>(std::_Sp_make_shared_tag, std::allocator<ndn::Data> const&) (shared_ptr_base.h:957)
> ==9806==    by 0x8DE0B6B: std::shared_ptr<ndn::Data>::shared_ptr<std::allocator<ndn::Data>>(std::_Sp_make_shared_tag, std::allocator<ndn::Data> const&) (shared_ptr.h:316)
> ==9806==    by 0x8DDFC5B: std::shared_ptr<ndn::Data> std::allocate_shared<ndn::Data, std::allocator<ndn::Data>>(std::allocator<ndn::Data> const&) (shared_ptr.h:598)
> ==9806==    by 0x8DDF103: std::shared_ptr<ndn::Data> std::make_shared<ndn::Data>() (shared_ptr.h:614)
> ==9806==    by 0x8FD6B9C: ns3::ndn::PacketHeader<ndn::Data>::Deserialize(ns3::Buffer::Iterator) (ndn-header.cpp:120)
> ==9806==    by 0xD912BAA: ns3::Packet::RemoveHeader(ns3::Header&) (packet.cc:290)
> ==9806==    by 0x8FF2F53: std::shared_ptr<ndn::Data const> ns3::ndn::Convert::FromPacket<ndn::Data>(ns3::Ptr<ns3::Packet>) (ndn-ns3.cpp:37)
> ==9806==    by 0x8FF18DD: ns3::ndn::NetDeviceFace::receiveFromNetDevice(ns3::Ptr<ns3::NetDevice>, ns3::Ptr<ns3::Packet const>, unsigned short, ns3::Address const&, ns3::Address const&, ns3::NetDevice::PacketType) (ndn-net-device-face.cpp:130)
> ==9806==
>  
> ==9806== 216,879 bytes in 201 blocks are indirectly lost in loss record 446 of 448
> ==9806==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==9806==    by 0xD8E7074: ns3::Buffer::Allocate(unsigned int) (buffer.cc:172)
> ==9806==    by 0xD8E6D93: ns3::Buffer::Create(unsigned int) (buffer.cc:141)
> ==9806==    by 0xD8E8666: ns3::Buffer::AddAtStart(unsigned int) (buffer.cc:331)
> ==9806==    by 0xD912A53: ns3::Packet::AddHeader(ns3::Header const&) (packet.cc:278)
> ==9806==    by 0xAD8A64A: ns3::PointToPointNetDevice::AddHeader(ns3::Ptr<ns3::Packet>, unsigned short) (point-to-point-net-device.cc:167)
> ==9806==    by 0xAD8E466: ns3::PointToPointNetDevice::Send(ns3::Ptr<ns3::Packet>, ns3::Address const&, unsigned short) (point-to-point-net-device.cc:502)
> ==9806==    by 0x8FF10E5: ns3::ndn::NetDeviceFace::send(ns3::Ptr<ns3::Packet>) (ndn-net-device-face.cpp:89)
> ==9806==    by 0x8FF150C: ns3::ndn::NetDeviceFace::sendData(ndn::Data const&) (ndn-net-device-face.cpp:111)
> ==9806==    by 0x8DF6F06: nfd::Forwarder::onOutgoingData(ndn::Data const&, nfd::Face&) (forwarder.cpp:377)
> ==9806==    by 0x8DF6455: nfd::Forwarder::onIncomingData(nfd::Face&, ndn::Data const&) (forwarder.cpp:333)
> ==9806==    by 0x8DEDA96: nfd::Forwarder::onData(nfd::Face&, ndn::Data const&) (forwarder.hpp:263)
> ==9806==
>  
> The valgrind output is rather long, I suggest you try generating it by yourself. I’m using Ubuntu 14.04, if that matters. 
> I’m not after chasing every single memory leak, though if it involves packets/packet based structures, there might be
> an issue with ndnSIM or even NFD, that could affect the testbed aswell.
>  
> In addition, I’ve tested ndn-simple with Frequency set to other values instead of 10, here is the resulting output:
> http://pastebin.com/0PZw40bk
>  
> I don’t think that roughly 1.6 MegaBytes of memory lost is a big deal, though given the size of the simulation and
> the number of interests transmitted, it might become a problem with larger simulations. I’m also not sure if this
> memory leaks is a result from lost packets or interests that were sent during the last millisecond of the simulation.
>  
> Anyway, I hope this post helps to find and reduce some memory leaks.
>  
> Best regards,
> Christian
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim