[fpc-pascal] Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64

Andrew Brunner andrew.t.brunner at gmail.com
Wed Oct 13 00:51:17 CEST 2010


After reading up on multi-core systems and memory barriers I decided
to do a few FPC stress tests with a brand new 6 core x64.
I tested this app on Ubuntu 10.10 x64 desktop release.   Using today's
FPC/Lazarus from svn.

The test case (attached) requires that you initialise before using.
The destroy button terminates the engine and all threads.  The engine
can be commanded to start/stop/set thread count.

If you initialise and start you will see the memory go up as expected.
 The problem is when you destroy the engine instance only to
initialise and start again, not all memory is re-claimed.

uThreads.TTestThread.Execute loops 0.5 billion iterations allocating
random string entries in a TStringArray. Inside the loop the engine
calls Empty(StringArray) to empty and reclaim memory of the simulated
log entry.  The empty procedure calls finalize on each element of the
string array and then setlength(list,0); to be sure there are no leaks
there.

The problem is noticeable when you create and destroy the engine (over
and over again) I used the Task Manager in Ubuntu for system resource
monitoring.  It shows the ThreadMemTest app eating more and more
resident memory as the system is initialised.  Starting and stopping
the engine also does a bit too but not nearly as bad.

The application is stable at running.  It can be
started/stopped/freed/created on the fly and when you exit the
application the program closes gracefully.  I don't get any read
access violations.  Meaning code execution order is certainly not a
suspect here.

This test case illustrates a FPC memory leak.  The thing I don't get
is where are the access violations?  Why is Linux reporting that
memory as still in use?

The interesting thing I have noticed was that Arrays[n] of boolean can
be used without memory barriers.  There is not one lock associated
with the boolean arrays and it always proves non-problematic on a 6
core system with 4gig ram.  There are boolean value checks that I did
inside the loops to see if any values were assigned out-of-order and
over the hours of tests I ran across up to 1200 threads... not one
false positive!

Any Memory sleuths interested to help?  Anyone interested in helping
me isolate the memory leak to submit a bug?  Anyone have comments on
this test case I'd like to submit?

If you could compile this on your box and report back if you had any
read access violations or suggestions to bypass/resolve the memory
issue I'm seeing here. Since the program is written to determine the
stability of FPC compiled apps, I didn't have time to add logging
features or anything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThreadMemTest.zip
Type: application/zip
Size: 7145 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20101012/c27cab62/attachment.zip>


More information about the fpc-pascal mailing list