Thanks for that. We're using -gh. We're aware of the usage requirements of heaptrc.
The cause of this problem in our case is very subtle. So far we have been unable to reproduce it outside our (very large) application but we're working on isolating it in a smaller test program. The problem looks like a dynamic array, created by Copy() inside an object's method, which is returned as the result of the method and assigned to a property (not a field) of another object (of a different class), is never released. This is the case even when the property to which it's assigned, is assigned a new value later on (at which point by our accounting, the reference count of the first array should have dropped to zero). We'll post more details or an example program when we have abstracted this problem from the rest of our application (in which application we have already eliminated all other known memory leaks using heaptrc). Are we correct to assume that as soon as no variable in our program, be it global, static, object field or property, refers to a dynamic array, the dynamic array will be released. Are we also correct to assume that the reassignment of any variable referring to a dynamic array to a new value will cause the previous array value to be released (presuming nothing else refers to this array)? Cheers, Bruce. leledumbo wrote: >> Are we missing something here or might this be an FPC bug? >> > > It depends on how you use HeapTrc. If via -gh, this might a bug. If you > manually include in a uses clause, you have to be sure that you put it as > the first one of your program. Otherwise, HeapTrc won't be able to detect > what have been done by units loaded before it. > _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal