How to find a dangling interface that causes an AV in Delphi

Question

I've a complex application to which I've just introduced some changes, adding a couple of new classes with interfaces and deleting some others. Functionally it all works but I get an access violation just after the Destroy procedure of a class:

"Access violation at address 0040B984 in module 'xxxx.exe'. Read of address 80808088".

I know this to be in the 'Finalize' code of the class and sure enough if I step into the dissassembly (Delphi 2010) I can see the point of the AV. I cannot see an easy way to find out which of my variables is triggering this though. Is there a procedure to be followed when going this deep that would get me a clue to the instance that is being referred-to?

Thanks Brian

Answer 1

This error looks like you are using FastMM for memory management. The error indicates that you are referring a pointer that has been cleared by FastMM with the DebugFillDWord value.

It means that you are using an interface that references to an object that has already been freed.
It also means you have not enabled CatchUseOfFreedInterfaces.

In order to change those, and to debug, you cannot do with the stock FastMM that comes with Delphi.
You will need to download FastMM (version 4.94).

After download:

Like gabr already mentions, inside FastMM4Options.inc, make sure you enable FullDebugMode and CatchUseOfFreedInterfaces (which disables CheckUseOfFreedBlocksOnShutdown, but you are not interested in the latter right now).
You might want to enable RawStackTraces as well; that depends if your current stack trace is good enough.

When you have done these settings, then run your app with FastMM through the debugger and put a breakpoint on this method inside the FastMM4 unit:

procedure TFreedObject.InterfaceError;

I have modified my FastMM4 unit a bit to get me more context info; I can share that with you (I have already mailed it to the FastMM4 team, but it has not been included in the official sources yet).

I wrote a pretty dense blog article on debugging using FastMM that might help you.
Drop a note here if that needs further explanation :-)

Good luck, and let us know if you need further directions.

--jeroen

Edit: 20100701 - emphasised the bits mentioned in Brian's comment.

Answer 2

In most cases such errors can be caught by using FastMM and compiling application with conditional defines FullDebugMode and CatchUseOfFreedInterfaces. Just make sure that you put FastMM4 in the first place in the dpr's 'uses' list.