> I'm MemProof-ing some of my apps, and came across a "Virtual Memory"
> leak. The code it points to is in Forms.pas, the
> MakeObjectInstance(Method: TWndMethod)
> function. The variable Block (PInstanceBlock) is not freed within the
> function.
It shouldn't be freed there. Block is being used as a temporary variable
for extending a linked list. When InstFreeList is nil, there is no more
room in the are reserved for holding object instances (InstBlockList).
InstFreeList points to the free area. Another page of memory is reserved
and tacked onto the end using Block to hold the location.
> It's been a while since I dealt with Lists (which is what this seems
> to be operating on), but isn't that correct? Isn't it that you can't
> free the pointer to the item you just added to the list?
Call FreeObjectInstance. It moves the object instance space back onto the
list of free spots.
> So. Assuming the
VCL code is doing what it *should* be doing, what
> could my app have done to generate this leak? It only occurs in one
> of the apps I've proofed.
You are right: the memory is never freed. That is by design. The est you
can do is contain the memory "leak." Call FreeObjectInstance when you can.
MakeObjectInstance only allocates more memory when it runs out of its
original allocation.
As I said, this behavior is by design. The memory is never really leaked
since InstFreeList and InstBlockList are always pointing to it or to
something that points to it. The only time that memory is truly leaked is
after your program finishes, at which point Windows frees any memory for
you anyway.
--Rob