<div dir="ltr"><div>Here are some more data points from Valgrind Massiff analysis. I have ran it for 25 and 50 nodes. <br><br></div>/anil.<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 2:26 AM, Anil Jangam <span dir="ltr"><<a href="mailto:anilj.mailing@gmail.com" target="_blank">anilj.mailing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Junxiao,<br><br></div>The memory leak is now closed by back porting the fix you referred to. However, the growth in memory consumption is still evident. This time, I believe it is a bloating of the process size. Can you please comment looking at the attached Valgrind logs if this is a legitimate requirement of NFD or it is just holding up the resources without really needing it?  I see the allocation emanating from RibManager and on receiving Interest as some of the major contributors. <br><br></div><div>Likewise you said earlier, these are perhaps fixed into main branch of NFD but not ported yet into the NFD of ndnSIM. Please check, reports are attached.<br><br></div>50 node simulation valgrind summary:<br>-------------------------------------------------------<br><div style="margin-left:40px">==9587== LEAK SUMMARY:<br>==9587==    definitely lost: 0 bytes in 0 blocks<br>==9587==    indirectly lost: 0 bytes in 0 blocks<br>==9587==      possibly lost: 2,263,514 bytes in 67,928 blocks<br><span style="background-color:rgb(255,255,0)">==9587==    still reachable: 1,474,943,776 bytes in 3,910,237 blocks</span><br>==9587==         suppressed: 0 bytes in 0 blocks<br>==9587== <br>==9587== For counts of detected and suppressed errors, rerun with: -v<br>==9587== ERROR SUMMARY: 37 errors from 37 contexts (suppressed: 0 from 0)<br></div><br></div>25 node simulation valgrind summary:<br>-------------------------------------------------------<br><div style="margin-left:40px">==9287== LEAK SUMMARY:<br>==9287==    definitely lost: 0 bytes in 0 blocks<br>==9287==    indirectly lost: 0 bytes in 0 blocks<br>==9287==      possibly lost: 400,259 bytes in 11,100 blocks<br><span style="background-color:rgb(255,255,0)">==9287==    still reachable: 437,147,930 bytes in 1,132,024 blocks</span><br>==9287==         suppressed: 0 bytes in 0 blocks<br>==9287== <br>==9287== For counts of detected and suppressed errors, rerun with: -v<br>==9287== ERROR SUMMARY: 31 errors from 31 contexts (suppressed: 0 from 0)<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">/anil.<br><br><div><div><br><br></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 7:42 AM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Anil<div><br></div><div>The call stack in the Valgrind report indicates that you are running NFD within ndnSIM.</div><div>#3236 is fixed in NFD commit 9c903e063ea8bdb324a421458eed4f51990ccd2c on Oct 04, 2015. However, ndnSIM's NFD fork is dated back on Aug 21, 2015, and doesn't contain the fix.</div><div>You may try to backport that commit to ndnSIM's NFD fork, or ask ndnSIM developers to upgrade their fork.</div><div><br></div><div>Yours, Junxiao<div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 5:23 PM, Anil Jangam <span dir="ltr"><<a href="mailto:anilj.mailing@gmail.com" target="_blank">anilj.mailing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Junxiao,<br><br></div>I am observing a memory leak with NFD and to verify the same I did couple of Valgrind enabled simulation runs with 25 and 50 nodes. Based on the Valgrind report, and output of 'top' command, I see that RAM consumption grows consistently and rapidly. My scaling test is affected that I am not able to run the simulation for longer time and/or with high number of nodes. Also, I see a very high number of timeouts<br></div></div><br></div>I see a NFD leak issue in closed state, which confirms this leak however closed owing to its small size. Perhaps this is showing up a high scale?<br><a href="http://redmine.named-data.net/issues/3236/" target="_blank">http://redmine.named-data.net/issues/3236/</a><br><br></div><div>Please check the attached Valgrind report. Let me know what other data you may need to debug this further. Also, please suggest a solution or workaround to this?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>/anil.<br><br></div></font></span></div></blockquote></div></div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>