I checked out FullDebugMode on FastMM. It is an amazing library. I
found a couple of errors in my code that seemed to be the source of
most of the problems. I just finished exercising a routine file
maintenance part of my program and found it to be leak free after
repairs. Since the leaks occurred in code that is common to (I think)
all of my file maintenance routines, I am hoping that those leaks are
history.

And I also exercised the most processing intense part of my code. I
found one error there that seemed to be at the root of the problems I
was having there. That part of my program now runs leak free as well
except for some strings that don't get released. According to the log
file generated by FastMM, the strings that don't get released are
apparently lost in SysUtils.TrimRight which seems to be called from
IB_Components.ApplyTrimming.

I'm amazed by the log from FastMM. If you have not used it and you
wonder if it would help you, here is an example with a stack trace
that shows where a leak occurs:

A memory block has been leaked. The size is: 20

Stack trace of when this block was allocated (return addresses):
402FE2 [System][@GetMem]
4058C1 [System][@NewAnsiString]
4058EC [System][@LStrFromPCharLen]
405D38 [System][@LStrCopy]
40EEFD [SysUtils][TrimRight]
5B37F1 [IB_Components.pas][IB_Components][ApplyTrimming][40017]
402FE2 [System][@GetMem]
4058C1 [System][@NewAnsiString]
405904 [System][@LStrFromPCharLen]

The block is currently used for an object of class: Unknown

Helen, I'm sorry that I did not find anything that applies to
CORE-1079. That seems pretty serious. For what it is worth, I got
much better information from FastMM than from MemProof.

Thanks to everyone for your help.

-Jack

> > You might also like to take a look at this:
> >
> > URL: http://tracker.firebirdsql.org/browse/CORE-1079
> >
> > If MemProof is providing anything insightful about detaches, it might
> > be useful to upload the relevant part of the MP log to the Tracker.
> >
> > Helen
> >
>