[fpc-pascal] Heap, Stack, HeapTrc and threads

[andrew.bennett at ns.sympatico.ca]

On: Thu, 24 Nov 2011 17:06:18 +0100  Jonas Maebe <jonas.maebe at elis.ugent.be> wrote

> On 24 Nov 2011, at 16:28, <andrew.bennett at ns.sympatico.ca> 
> <andrew.bennett at 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