Hmm, I did. Apparently mantis did not register this? Done it again.
Closed now. -b
Joost van der Sluis wrote:
> Op dinsdag 26-05-2009 om 10:16 uur [tijdzone +1000], schreef Bruce
> Tulloch:
>
>> Confirmed fixed in r13195 as tested with the application in which this
>> was originally discovered,
Op dinsdag 26-05-2009 om 10:16 uur [tijdzone +1000], schreef Bruce
Tulloch:
> Confirmed fixed in r13195 as tested with the application in which this
> was originally discovered, thanks Jonas.
In that case, can you close the bug report? So we know that we don't
have to look at this issue anymore?
Confirmed fixed in r13195 as tested with the application in which this
was originally discovered, thanks Jonas.
Bruce Tulloch wrote:
> I've reported this as an FPC bug:
>
> http://bugs.freepascal.org/view.php?id=13820
>
> Cheers, Bruce.
>
___
fpc-pa
I've reported this as an FPC bug:
http://bugs.freepascal.org/view.php?id=13820
Cheers, Bruce.
Bruce Tulloch wrote:
> 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 w
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 Inte
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 t
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 expec
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 varia
Thanks for that. We're using -gh. We're aware of the usage requirements
of heaptrc.
The cause of this problem in our case is very subtle. So far we have
been unable to reproduce it outside our (very large) application but
we're working on isolating it in a smaller test program.
The problem looks
> Are we missing something here or might this be an FPC bug?
It depends on how you use HeapTrc. If via -gh, this might a bug. If you
manually include in a uses clause, you have to be sure that you put it as
the first one of your program. Otherwise, HeapTrc won't be able to detect
what have been d
On 24 May 2009, at 09:29, Bruce Tulloch wrote:
Are we missing something here or might this be an FPC bug?
We'll file a bug report if necessary.
A bug report with a compilable example program that demonstrates the
problem would be helpful, thanks.
Jonas
PS: your message was held for mod
When building an application with Lazarus (r20153) using FPC (r13188)
(on a Debian Lenny system) we are experiencing significant memory leaks.
Earlier revisions of both Lazarus and FPC 2.3.1 experience the same problem.
Building and running our app with heaptrc enabled we find a very large
number
12 matches
Mail list logo
