[fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188

[Bruce Tulloch]

Ok, I don't think that caveat does not applies in this case, we neither
call halt nor share these particular variables between threads (we do
have threads in this application however). What we do see when freeing
(ie, assigning to nil) some of these variables is a jump from recount =
1 (as we expect at this point in our application) to refcount = 7 on
some blocks. There is no way (in our application) that there are 7
references to these blocks. We are investigating and report further as
soon as we have some more concrete data to feed back to you.

Bruce.

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).

Jonas Maebe wrote:
>
> On 25 May 2009, at 07:38, Bruce Tulloch wrote:
>
>> Are we correct to assume that as soon as no variable in our program, be
>> it global, static, object field or property, refers to a dynamic array,
>> the dynamic array will be released. Are we also correct to assume that
>> the reassignment of any variable referring to a dynamic array to a new
>> value will cause the previous array value to be released (presuming
>> nothing else refers to this array)?
>
> Yes.
>
> One caveat is that the memory may not be immediately released after
> the last reference that you know of disappears, because there may
> still be temporary memory locations (implicitly created by the
> compiler while evaluating expressions) containing a reference. Such
> temporary locations will be finalised either when they are reused by
> the compiler later on, or when the function in which they were created
> by the compiler exits (such temporary locations can never survive the
> scope in which they were created by the compiler).
>
> However, this could only cause the behaviour you are seeing if you
> were to call halt() somewhere in a deeply nested function and some
> temporary locations in a parent stack frame still contained
> references, or of you call halt() while some threads are still running
> that have local variables/temporaries that point to such variables.
>
>
> Jonas
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal