On: Thu, 24 Nov 2011 17:06:18 +0100 Jonas Maebe <jonas.ma...@elis.ugent.be> wrote
> On 24 Nov 2011, at 16:28, <andrew.benn...@ns.sympatico.ca> > <andrew.benn...@ns.sympatico.ca > > wrote: > > ... > > only odd thing was that TotalAllocated sometimes came back negative in > > the threads as the program approached the point of running out of > > memory > > 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 Thank you for pointing this out. > > > 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. Ah! Light dawns. So my problems did not arise entirely from my incompetence in handling storage allocation. Thanks for the morale boost! > 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). I had not realized I could do this! My thought processes ran "C -> Unix -> not me under Windows" and I am currently stuck with Windows. > > Jonas Many thanks, Andrew Bennett _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
