Since the number of threads is set at compile time, I didn't expect to see the much memory creep. The resource monitor for the process shows about 15Mb of memory used. When the first group of 50 threads was created and ran that climbed another 5 to about 20MB. Then every time the system created / destroyed / created itself it added an additional 100kb.
So I ran an automation of this last night. I was expecting to see the system to be well into 100s of MB of RAM and the virtual memory way past the 3gigs as reported. That was not the case. Physical memory stopped creaping up at 45mb and the virtual memory peaked out at 4gigs over the course of the entire night. Meaning threads were created/destroyed/ and new ones were created over and over again. The program exited gracefully as well this morning. >> This test case illustrates a FPC memory leak. I realised when I wrote that, that it may not be entirely accurate so that's why I did the automation all night to see how bad things might be. It turns out that things remained stable and creep levelled out but it was very strange to see. On Wed, Oct 13, 2010 at 1:58 AM, Florian Klaempfl <flor...@freepascal.org> wrote: > Am 13.10.2010 00:51, schrieb Andrew Brunner: >> >> This test case illustrates a FPC memory leak. > > What makes you think so? Internally freed memory is not immediatly > released to the OS as well. On windows I know there is a call to flush all virtual memory out. Is there a wrapper in fpc for *nix and windows? _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
