CODEWITHSUNDEEP
delphipointersfree
spspli
spspli

Reputation: 3338

Where is this invalid pointer?

I have following code (I checked objCur is not Nil before free}:

try
  objCur.Free;
Except on E:Exception do
  begin
    OutputDebugString(PChar('Exception '+E.Message));
    Assert(False);
  end;
end;

It report this exception message:

Invalid pointer operation. objCur is TXX_TEA type.
objCur: TXX_TEA;

In TXX_TEA.Destroy I have following code

destructor TXX_TEA.Destroy;
begin
  OutputDebugString(PChar('Inside Destroy'));
  ...
  inherited;
  OutputDebugString(PChar('End of Destroy'));
end;

In debugView I see following messages:

Inside Destroy
...
End of Destroy

Exception: Invalid pointer operation

I know objCur.Free calls TXX_TEA.Destroy, but it looks TXX_TEA.Destroy executes without error. So where should I trace this invalid pointer operation?

Upvotes: 3

Views: 2142

Answers (3)

Mason Wheeler
Mason Wheeler

Reputation: 84550

An Invalid Pointer Operation when you're trying to free something almost always means that it's already been freed. If you want to find where, the simplest way is to get the full version of FastMM from SourceForge. Read the documentation and it'll show you how to add it to your project and how to turn on FullDebugMode. With FullDebugMode on, when you try to free something that's already been freed, it'll interrupt the program with a dialog box that gives you, among other things, a stack trace for when the object was freed the first time. That should help you track the error down.

Upvotes: 6

Rob Kennedy
Rob Kennedy

Reputation: 163277

An invalid pointer operation occurs when the memory manager is asked to release memory that doesn't belong to it.

An object's memory is freed just before the outermost destructor returns to the caller. The caller in this case is TObject.Free. Calling inherited does not cause an object's memory to be freed because the compiler knows that it's not the outermost call.

Evidently, you're freeing an object that doesn't really exist, but the contents of the memory for this supposed object look valid enough that the code in the destructor that cleans up object's fields doesn't crash. It's only when the destructors finish running, and the object is going to be freed, that the memory manager detects that the address doesn't refer to anything currently allocated.

Upvotes: 9

Rudy Velthuis
Rudy Velthuis

Reputation: 28806

It is very likely that you still have a reference to it and that some code uses that reference to access the object after is was freed. This can be an object reference or an interface reference (interfaces refs that are not nil will call _Release at the end of scope).

We'd have to see more code to really find out what causes it.

Upvotes: 3

Related Questions