On Sun, 9 Nov 2014, Xiangrong Fang wrote:
2014-11-09 22:14 GMT+08:00 Xiangrong Fang <xrf...@gmail.com>:
2014-11-09 22:05 GMT+08:00 Tomas Hajny <xhaj...@hajny.biz>:
On 9 Nov 14, at 21:58, Xiangrong Fang wrote:
Are you sure that it really is endless (i.e. did you let to run for a
sufficiently long time)? If you increase the amount of allocated
blocks (which is what happens in case of increasing your constant),
traversing through all the blocks (especially if they are not freed
at the end) may indeed take fairly long time...
You are right Tomas, it finished, generated a 300M+(!) trace file, looks like
this:
Heap dump by heaptrc unit
8137678 memory blocks allocated : 258591549/258591552
5226767 memory blocks freed : 142155109/142155112
2910911 unfreed memory blocks : 116436440
True heap size : 951812096
True free heap : 392917184
Should be : 462779048
Call trace for block $00007F57C456D680 size 40
$000000000040071F line 29 of demo.lpr
$0000000000400180
The last 3 likes repeated until the end of 300M log data!
Why when ITEM_COUNT is small, there is no memory leak, but when it is large,
there are so many leaks?
I didn't check in detail, but looking at the code, it seems likely that you overwrite
memory somewhere in your tcache class. As soon as that happens somewhere, memory is
corrupted and is unlikely to be free corrected.
The greater the number of items, the greater the probability of memory
corruption.
Code like this:
ci := PCacheItem((buf + SizeOf(Pointer) * Random(FDepth))^);
for i := 0 to FDepth - 1 do begin
slot := buf + SizeOf(Pointer) * i;
if Pointer(slot^) = nil then begin
Inc(N);
Pointer(slot^) := GetMem(SizeOf(TCacheItem));
ci := PCacheItem(slot^);
makes me frown, because the first assignment to ci is useless, so highly
suspect.
Michael._______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
