<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial">2014-11-09 22:14 GMT+08:00 Xiangrong Fang </span><span dir="ltr" style="font-family:arial"><<a href="mailto:xrfang@gmail.com" target="_blank">xrfang@gmail.com</a>></span><span style="font-family:arial">:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><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 class="gmail_extra"><span class=""><div style="font-family:'courier new',monospace"><span style="font-family:arial">2014-11-09 22:05 GMT+08:00 Tomas Hajny </span><span dir="ltr" style="font-family:arial"><<a href="mailto:XHajT03@hajny.biz" target="_blank">XHajT03@hajny.biz</a>></span><span style="font-family:arial">:</span><br></div></span><div class="gmail_quote"><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"><span class="">On 9 Nov 14, at 21:58, Xiangrong Fang wrote:<br><div><div><br>
</div></div></span><span class="">Are you sure that it really is endless (i.e. did you let to run for a<br>
sufficiently long time)? If you increase the amount of allocated<br>
blocks (which is what happens in case of increasing your constant),<br>
traversing through all the blocks (especially if they are not freed<br>
at the end) may indeed take fairly long time...<br></span></blockquote><div><br></div><div style="font-family:'courier new',monospace">​You are right Tomas, it finished, generated a 300M+(!) trace file, looks like this:</div><div style="font-family:'courier new',monospace"><br></div></div></div></div>
</blockquote></div><div class="gmail_default" style="font-family:'courier new',monospace">​Heap dump by heaptrc unit</div><div class="gmail_default" style="font-family:'courier new',monospace">8137678 memory blocks allocated : 258591549/258591552</div><div class="gmail_default" style="font-family:'courier new',monospace">5226767 memory blocks freed     : 142155109/142155112</div><div class="gmail_default" style="font-family:'courier new',monospace">2910911 unfreed memory blocks : 116436440</div><div class="gmail_default" style="font-family:'courier new',monospace">True heap size : 951812096</div><div class="gmail_default" style="font-family:'courier new',monospace">True free heap : 392917184</div><div class="gmail_default" style="font-family:'courier new',monospace">Should be : 462779048</div><div class="gmail_default" style="font-family:'courier new',monospace">Call trace for block $00007F57C456D680 size 40</div><div class="gmail_default" style="font-family:'courier new',monospace">  $000000000040071F line 29 of demo.lpr</div><div class="gmail_default" style="font-family:'courier new',monospace">  $0000000000400180</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">The last 3 likes repeated until the end of 300M log data!</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Why when ITEM_COUNT is small, there is no memory leak, but when it is large, there are so many leaks?</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Xiangrong​</div><br></div></div>