On 24 Nov 2011, at 16:28, <andrew.benn...@ns.sympatico.ca> <andrew.benn...@ns.sympatico.ca
> wrote:
At no point did the heap status reveal the growing amount of space
tied up: the
only odd thing was that TotalAllocated sometimes came back negative in
the threads as the program approached the point of running out of
memory
(at the 2GB addressing limit; the machine has 6GB).
The fact that the heap status counters are unreliable since the latest
rewrite of the heap manager is a known problem:
* http://bugs.freepascal.org/view.php?id=15805
* http://bugs.freepascal.org/view.php?id=14315
* http://bugs.freepascal.org/view.php?id=15763
In the course of eliminating the workspace originally allocated as
dynamic
arrays, I discovered 2 unmatched SetLength procedures. As I mentioned
above, these were never reported by HeapTrc.
That's because they don't cause memory leaks (except in case of direct
pointer manipulations, but in that case crashes are more likely than
memory leaks). Memory management for dynamic arrays and ansi/wide/
unicodestrings is automatic via (hidden) reference counting.
I've never seen any reports of heaptrc failing to report memory leaks.
Most likely, your problems stem from internal heap fragmentation
rather than from memory leaks. Such problems can usually be solved by
using the "cmem" unit, which falls back to the default C library's
memory manager (FPC's heap manager is generally faster, except in
cases of lots of fragmentation).
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
