The Wiert Corner - irregular stream of stuff: jpluimers

Paul Thornton posted a nice question on G+ two weeks ago:

Interfaces are great, but they can be a pain to debug. Forgetting one weak link can lead to Access Violation hell. I seem to remember a utility that would let you visualise the links between interfaced objects, but can’t remember what it was called. Anybody know?

Do you have any clever interface debugging tips or tricks?

Mixing object and interface references leads to complex situations, especially when some classes make refcounting go away (not limited to UI components) so refactoring is a good idea, it at all possible:

Lars Dybdahl:

Refactor them away :-)

When the mix of interface reference counting and TObject gets so complex, that the source code is no longer obvious, maintenance costs sometimes become too high and another solution might be better.

Nicholas Ring:

+Lars Dybdahl Totally agree and it is even worse when reference counting is disabled (like adding an interface reference to an UI component).

There is not much tooling, this thread only mentioned RefCountTracer and FastMM:

Steffen Binas:

There is this: https://github.com/AquaSoftGmbH/RefCountTracer

It helps you find memoryleaks, but also could show you if a refcount goes below 0.

Paul Thornton:

This link was very useful. It also points to a good FastMM tutorial.

Which reminded me I totally forgot to post that tutorial on my blog so here it is:

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.

–jeroen

via: Interfaces are great, but they can be a pain to debug. Forgetting one weak link….