I think I've nailed and example of the problem; when Copy() is called
with the result of another Copy() the reference count for the returned
array is not managed correctly when compiled with -MDelphi.
A trivial example program, copytest.pas:
program copytest;
var
S, D : array of Integer;
begin
SetLength(S,4000);
D := Copy(Copy(S));
end.
which when compiled with:
fpc -MDelphi -gl -gh copytest.pas
and run produces the following:
lenin:$ ./copytest
Heap dump by heaptrc unit
3 memory blocks allocated : 48024/48024
2 memory blocks freed : 32016/32016
1 unfreed memory blocks : 16008
True heap size : 262144
True free heap : 246048
Should be : 246072
Call trace for block $B7F4BF50 size 16008
$080480EA main, line 8 of copytest.pas
$080657A7
I hope this helps diagnose what's happening here.
Note that if compiled without -MDelphi it works correctly but in our
case we need to use -MDelphi because our application is also built
with Delphi and Kylix3.
Cheers, Bruce.
Jonas Maebe wrote:
>
> On 25 May 2009, at 10:30, Bruce Tulloch wrote:
>
>> PS: does the attribute "compilerproc" mean the function is defined to be
>> called by the compiler implicitly? We have rebuilt the FPC RTL with
>> debug enabled to further diagnose what's happening here (which is why we
>> came across it).
>
> It means that the procedure becomes invisible to regular Pascal code,
> and that it gets a particular internal symbol name. Such routines are
> indeed called implicitly by the compiler for various purposes.
>
>
> Jonas
> _______________________________________________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
