[ndnSIM] High Memory Usage & Potential Memory Leaks

Wed Feb 18 01:02:31 PST 2015

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::_S
p_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_m
ake_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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20150218/8aa4a6d3/attachment.html>