Delphi EInvalidPointer — What It Means & How to Fix It

What Does This Error Mean?

EInvalidPointer means your program tried to free or reallocate a memory block using a pointer that the Delphi memory manager does not recognize as valid. The most common cause is freeing the same object twice (double-free), or calling Free on a pointer that was not allocated by Delphi's memory manager. This is a serious memory corruption bug.

Affected Models

All Delphi versions
RAD Studio
FastMM memory manager

Common Causes

Freeing the same object or pointer twice — calling Free or Dispose on something that was already freed
Calling Free on a stack-allocated variable instead of a heap-allocated object
Passing a pointer to FreeMem that was not originally allocated with GetMem or New
Memory corruption from an earlier bug that has overwritten the heap headers
Using the wrong memory manager — mixing objects allocated by one DLL's memory manager and freed by another

How to Fix It

Enable FastMM4 in full debug mode by adding it as the first unit in your DPR file and setting FullDebugMode. It reports the exact location of double-frees and invalid pointer operations.

FastMM is the default memory manager in Delphi 2006+. Enable its debug mode with conditional defines.
Use FreeAndNil() instead of just Free(). FreeAndNil sets the variable to nil after freeing — so a second accidental Free call is ignored (freeing nil is always safe).

Replace: MyObj.Free; with: FreeAndNil(MyObj); — this one change prevents most double-free bugs.
Never call Free on a variable allocated on the stack (a local variable that is not an object). Only heap-allocated objects created with a constructor can be freed with Free.

Records declared as local variables live on the stack and must not be freed. Only pointer-to-record allocated with New() can be freed with Dispose().
If your application uses DLLs, make sure all DLLs share the same memory manager. Include ShareMem as the first unit in both the DPR and all DLL projects.

When DLLs have separate memory managers, memory allocated in one DLL cannot be safely freed in another.
Review code that manually manages pointer memory (GetMem/FreeMem, New/Dispose). Make sure each allocation has exactly one corresponding deallocation, and that the correct deallocation function is used for how it was allocated.

GetMem/FreeMem are paired. New/Dispose are paired. Do not mix them.

When to Call a Professional

EInvalidPointer indicates serious memory management issues that require careful debugging. Enable FastMM in full debug mode — it will pinpoint exactly which pointer was invalid and often shows where the object was originally allocated and freed. If you are mixing DLLs, ensure all DLLs share the same memory manager.

Frequently Asked Questions

What is a double-free and why is it dangerous?

A double-free means you freed the same memory block twice. The first free returns the memory to the heap manager. The second free passes back a pointer to memory the heap manager no longer considers allocated — this corrupts the heap's internal data structures. The resulting corruption can cause EInvalidPointer immediately, or cause mysterious crashes much later in unrelated code.

Why does FreeAndNil prevent double-free bugs?

FreeAndNil calls Free and then sets the variable to nil. In Delphi, calling Free on a nil object is explicitly safe and does nothing. So if you accidentally call FreeAndNil twice, the second call sees nil and exits immediately. Make FreeAndNil your default way to release objects.

What is FastMM and how do I get it?

FastMM is Delphi's default memory manager since Delphi 2006. In debug mode it tracks every allocation and provides detailed reports when something goes wrong. For older Delphi versions, you can add FastMM4 manually from its open-source repository. For Delphi 10.4+, there is also FastMM5 with even better diagnostics.