Giuliano Colla wrote:
willem ha scritto:
willem wrote:
Giuliano Colla wrote:
Al Boldi ha scritto:
For now, when you start a thread non-suspended,
TThread.Execute(false), can you see the memory increase for your
project1 app when checking with top? Then, when you
TThread.WaitFor/TThread.Free, does it decrease? And by how much?
Below is the simplified console app.
Thanks for the feedback!
Feedback:
I couldn't see any change with top, so I slightly modified your
console app, by adding:
writeln('Type <Enter> to start thread');
readln(ans);
before
t1:=TThreadBug.Create(false);
With Lazarus 0.9.4.1, fpc 2.2.0 the result is the following:
before starting the thread TOP says:
4732 colla 16 0 2564 808 488 S 0 0.1 0:00.00 threadbug
after the thread is started it becomes:
4732 colla 15 0 12860 916 576 S 0 0.1 0:00.00 threadbug
and it doesn't change anymore until program termination, either
typing y or n.
I tried to set true FreeOnTerminate of your thread (with proper
adjustments, because WaitFor and Free don't work anymore, of
course) but there's no change.
For sake of completeness, I made the same with my test program,
where I can terminate, free and restart the thread multiple times,
and I see the memory usage increasing each time: it started with
12Kb and I stopped when it had become 122Mb! However all memory is
released before closing the program, because heaptrc correctly
reports an increasing number of blocks allocated and freed, as a
function of the number of times I started my thread.
As soon as I can, I'd like to perform the same tests with Kylix, to
see if it makes a difference.
Regards,
Giuliano
I do not think this a fpc problem.
In the threat ring benchmark Free Pascal performs almost as well as C.
I did run this benchmark without problems.
Regards Wim
I am using kubuntu gutsy.
lazarus 0.9.24 -386-linux-gtk
fpc 2.2.0
and I run the threatbug with no memory leaks.
i did remove the readln 's and added a for loop.
threadbug ran then 10 000 times without memory leaks on my system.
I've realized that information from top is not detailed enough, as it
shows only cumulative memory usage. So I've made a more careful
analysis using pmap, which provides the memory map of a process.
(Usage: pmap [-x] | [-d] PID )
It turns out is that libpthread allocates a 10MB memory chunk (10240Kb
to be exact) when a thread is created, and doesn't release it when the
thread is destroyed. But it reuses the same chunk when the thread is
created again.
So the leakage occurs just once.
This as far as fpc 2.2.0 is concerned, in a simple context as that of
threadbug.
With Lazarus, in a slightly more complex test, using the synchronize
method you may find as many 10240 kb blocks allocated as the times you
started and freed the thread, unless you add an extra WaitFor after
teminating the thread, which shouldn't be necessary with FreeOnTerminate.
IMHO it's a combination of an fpc bug (there's no reason to keep a
10MB memory block when there's no thread using it) with some obscure
Lazarus bug which doesn't allow the thread to fully terminate.
Attached is a portion the output of pmap (before starting the thread,
after running, and after destroy) for a test where I'd added a large
array to the threadbug code: this accounts for an extra 62528 Kb which
are correctly allocated and set free.
Regards,
Giuliano
well I made 10 copy's of threadbug and run them in parallel. In my case
libpthread does not allocate a 10 Mb memory block, because
the 10 processes should allocate 100Mb of memory Top does show only a
sligth increase in memory . On my kubuntu there are
145 processes allocated . So i can not reproduce your problem.
Regards Wim.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
