<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.E-MailFormatvorlage17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=DE>Hi,<o:p></o:p></span></p><p class=MsoNormal><span lang=DE><o:p> </o:p></span></p><p class=MsoNormal>using the latest version of ndnSIM and ndn-cxx, I’ve noticed a rather high memory usage (several gigabytes, with<o:p></o:p></p><p class=MsoNormal>content store set to 1 packet) in simulations involving plenty of interests and data packets. So I’ve compiled ndnSIM <o:p></o:p></p><p class=MsoNormal>in debug mode and started the ndn-simple example (from scratch directory) with valgrind active, here is the <o:p></o:p></p><p class=MsoNormal>summary of the output.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>./waf --command-template="valgrind --leak-check=full --show-reachable=yes %s" --run ndn-simple<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>==9678== 1,738,712 (408 direct, 1,738,304 indirect) bytes in 3 blocks are definitely lost in loss record 448 of 448<o:p></o:p></p><p class=MsoNormal>==9678==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<o:p></o:p></p><p class=MsoNormal>==9678==    by 0x5AD027F: ns3::Ptr<ns3::Node> ns3::CreateObject<ns3::Node>() (object.h:423)<o:p></o:p></p><p class=MsoNormal>==9678==    by 0xD9C8CFA: ns3::NodeContainer::Create(unsigned int) (node-container.cc:137)<o:p></o:p></p><p class=MsoNormal>==9678==    by 0x41C856: ns3::main(int, char**) (ndn-simple.cc:63)<o:p></o:p></p><p class=MsoNormal>==9678==    by 0x41D2D7: main (ndn-simple.cc:107)<o:p></o:p></p><p class=MsoNormal>==9678== <o:p></o:p></p><p class=MsoNormal>==9678== LEAK SUMMARY:<o:p></o:p></p><p class=MsoNormal>==9678==    definitely lost: 408 bytes in 3 blocks<o:p></o:p></p><p class=MsoNormal>==9678==    indirectly lost: 1,738,304 bytes in 8,257 blocks<o:p></o:p></p><p class=MsoNormal>==9678==      possibly lost: 98 bytes in 3 blocks<o:p></o:p></p><p class=MsoNormal>==9678==    still reachable: 656 bytes in 33 blocks<o:p></o:p></p><p class=MsoNormal>==9678==         suppressed: 0 bytes in 0 blocks<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>At first, this looks like that the memory lost is only when creating a node, which is not good, but would be “okay” for <o:p></o:p></p><p class=MsoNormal>simulations. But when you dig deeper into the generated output of valgrind, you will find that the problem is caused<o:p></o:p></p><p class=MsoNormal>by several allocations about packets, regular expressions, skiplists in content store, etc… I’m not an expert in that field, <o:p></o:p></p><p class=MsoNormal>but I thought it is worth mentioning on the mailing list.<o:p></o:p></p><p class=MsoNormal>Example of the most important ones:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>==9806== 238,400 bytes in 200 blocks are indirectly lost in loss record 447 of 448<o:p></o:p></p><p class=MsoNormal>==9806==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8DDF103: std::shared_ptr<ndn::Data> std::make_shared<ndn::Data>() (shared_ptr.h:614)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8FD6B9C: ns3::ndn::PacketHeader<ndn::Data>::Deserialize(ns3::Buffer::Iterator) (ndn-header.cpp:120)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xD912BAA: ns3::Packet::RemoveHeader(ns3::Header&) (packet.cc:290)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8FF2F53: std::shared_ptr<ndn::Data const> ns3::ndn::Convert::FromPacket<ndn::Data>(ns3::Ptr<ns3::Packet>) (ndn-ns3.cpp:37)<o:p></o:p></p><p class=MsoNormal>==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)<o:p></o:p></p><p class=MsoNormal>==9806==<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>==9806== 216,879 bytes in 201 blocks are indirectly lost in loss record 446 of 448<o:p></o:p></p><p class=MsoNormal>==9806==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xD8E7074: ns3::Buffer::Allocate(unsigned int) (buffer.cc:172)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xD8E6D93: ns3::Buffer::Create(unsigned int) (buffer.cc:141)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xD8E8666: ns3::Buffer::AddAtStart(unsigned int) (buffer.cc:331)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xD912A53: ns3::Packet::AddHeader(ns3::Header const&) (packet.cc:278)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xAD8A64A: ns3::PointToPointNetDevice::AddHeader(ns3::Ptr<ns3::Packet>, unsigned short) (point-to-point-net-device.cc:167)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0xAD8E466: ns3::PointToPointNetDevice::Send(ns3::Ptr<ns3::Packet>, ns3::Address const&, unsigned short) (point-to-point-net-device.cc:502)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8FF10E5: ns3::ndn::NetDeviceFace::send(ns3::Ptr<ns3::Packet>) (ndn-net-device-face.cpp:89)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8FF150C: ns3::ndn::NetDeviceFace::sendData(ndn::Data const&) (ndn-net-device-face.cpp:111)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8DF6F06: nfd::Forwarder::onOutgoingData(ndn::Data const&, nfd::Face&) (forwarder.cpp:377)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8DF6455: nfd::Forwarder::onIncomingData(nfd::Face&, ndn::Data const&) (forwarder.cpp:333)<o:p></o:p></p><p class=MsoNormal>==9806==    by 0x8DEDA96: nfd::Forwarder::onData(nfd::Face&, ndn::Data const&) (forwarder.hpp:263)<o:p></o:p></p><p class=MsoNormal>==9806==<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The valgrind output is rather long, I suggest you try generating it by yourself. I’m using Ubuntu 14.04, if that matters. <o:p></o:p></p><p class=MsoNormal>I’m not after chasing every single memory leak, though if it involves packets/packet based structures, there might be<o:p></o:p></p><p class=MsoNormal>an issue with ndnSIM or even NFD, that could affect the testbed aswell.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In addition, I’ve tested ndn-simple with Frequency set to other values instead of 10, here is the resulting output:<o:p></o:p></p><p class=MsoNormal><a href="http://pastebin.com/0PZw40bk">http://pastebin.com/0PZw40bk</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I don’t think that roughly 1.6 MegaBytes of memory lost is a big deal, though given the size of the simulation and<o:p></o:p></p><p class=MsoNormal>the number of interests transmitted, it might become a problem with larger simulations. I’m also not sure if this<o:p></o:p></p><p class=MsoNormal>memory leaks is a result from lost packets or interests that were sent during the last millisecond of the simulation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Anyway, I hope this post helps to find and reduce some memory leaks.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best regards,<o:p></o:p></p><p class=MsoNormal>Christian<o:p></o:p></p></div></body></html>