FastMM4 and False Positives

[Sue King 5]

Delphi Rio Update 1, Win x64, 32 bit FMX application

 

I am currently working with a third party component library.  When I use one of the components, FastMM4 (4.991) is reporting an interface being used after being freed as the app closes down.

 

When contacted, the supplier of the product responded that there had not been any other reports of this happening, and perhaps it was a false positive.  The suggestion is to use the default memory manager, as this doesn't show any errors.

I have been using FastMM4 for years, and have never had an issue before.  However my code isn't nearly as complex as that in the component in question.

 

I can avoid the error being reported by turning off CatchUseOfFreedInterfaces.  Unfortunately I then get an AV with memory accessed at $80808080 and heaps of other memory leak errors that makes debugging very slow as every time the program exits I have to wait for the memory leak report, which I need to check my own code. 

 

At the moment, I feel I need to avoid using the component.

 

Is a false positive a likely scenario ? Do other people get false positives when using FastMM4  ?

 

TIA,

Sue

 

 

[David Heffernan 2353]

The component vendor is applying a development methodology known as "wishful thinking". 

 

FastMM4 doesn't get this wrong. 

[Sherlock 663]

@David HeffernanThank you for that great start into an otherwise dark day!

 

@Sue King Try to create a simple example using that component which still produces the error. Surely this will convince the vendor of their mistake.

[Sue King 5]

@Sherlock The message I sent to the vendor described a very simple example that showed the error.  I have referenced this forum for them to see responses to my inquiries, so hopefully they will see @David Heffernan 's response and have another look into it.

[Stefan Glienke 2019]

There are no false positives to this - if FastMM reports this it's true. These errors are usually very subtle and the reference to that  freed instance might only live a few cycles more and unless there does not happen another memory allocation that might reuse this particular piece of memory there will never be a defect (in terms of an AV happening or something) which is why this usually goes unnoticed by most until you enable this option which is not part of the build-in FastMM version (which is a shame!).

 

It's unbelievable how ignorant some vendors can be...

Edited May 21, 2019 by Stefan Glienke

[David Schwartz 430]

These are usually just problems in ordering of Free statements within Destructors.

 

Since Interfaces are freed automatically, it's likely complaining that the Interface is being freed before something created within it is getting freed.

 

Alternatively, the Interface is going out-of-scope before it should, and getting destroyed earlier than expected.

 

Try putting breakpoints on all of the Free() and FreeAndNil methods being called in whatever is attached or derived from that Interface.

[Matt Allwood 0]

I had similar things once I turned on this option in the legacy code I manage.

 

All that was required was to add a few MyInterfaceReference := nil statements in the destructors of classes where the class kept an interface reference as a field. I'd not been explicitly nilling references until then and relied on the reference counting to handle it for me. I saw no other side-effects from the 'use of freed instances' issue before or after the code change - I just left it in to stop FastMM4 moaning about them.

[Dalija Prasnikar 1404]

Problem with TComponent (and subsequently its descendants) is that it implements interfaces but has reference counting disabled in _AddRef and _Release methods so it can be used like regular class. 

 

However, people often forget that in such cases  _AddRef and _Release calls even though they don't do any counting will still be inserted by compiler and called for any interface reference to such object instance. So if there is alive interface reference to the object after calling Free that interface reference will contain dangling pointer and when such interface goes out of scope _Release will be called on already nuked object. While you may get away with such call without FastMM debugging mode, if it is turned on it will correctly identify the problem.

 

Simple test case that will blow with FastMM in debug mode

 

procedure TestComponent;
var
  Comp: TComponent;
  Intf: IInterface;
begin
  Comp := TComponent.Create(nil);
  Intf := Comp;
  Comp.Free;
end;

 

Edited May 21, 2019 by Dalija Prasnikar

[Sue King 5]

Thank you all for your responses.  The vendor is looking into this.

[Sherlock 663]

Peer pressure FTW!

[Sue King 5]

Possibly, although the assurance that it isn't a false positive maybe have been the deciding factor.

[Sue King 5]

The component vendor has investigated the code and believes this is a false positive. They are interested in making contact with someone working on FastMM to try to resolve it.  Who should I suggest ?

 

TIA

[Dalija Prasnikar 1404]

1 hour ago, Sue King said:

The component vendor has investigated the code and believes this is a false positive. They are interested in making contact with someone working on FastMM to try to resolve it.  Who should I suggest ?

Chances that it is false positive are about the same as chances you will get eaten up by black hole tomorrow. 

 

They need to fix their code. I gave you scenario (code) how this can happen, and something similar happens in their code.

[David Heffernan 2353]

Component vendor is wrong. 

[Fr0sT.Brutal 900]

On 9/20/2019 at 10:07 AM, Sue King said:

The component vendor has investigated the code and believes this is a false positive. They are interested in making contact with someone working on FastMM to try to resolve it.  Who should I suggest ? 

 

TIA

https://github.com/pleriche/FastMM4

 

Meanwhile to circumvent the report look at "expected leaks" feature. I've never used it myself but it sounds like something that shall help in your situation

Edited September 23, 2019 by Fr0sT.Brutal
tip added

[Stefan Glienke 2019]

2 hours ago, Fr0sT.Brutal said:

Meanwhile to circumvent the report look at "expected leaks" feature. I've never used it myself but it sounds like something that shall help in your situation

The issue is not a memory leak but the use of an interface reference after the object behind it was destroyed already - see first post.

[Sue King 5]

Thank you for your responses.

[Fr0sT.Brutal 900]

20 hours ago, Stefan Glienke said:

The issue is not a memory leak but the use of an interface reference after the object behind it was destroyed already - see first post.

Ah yes you're right.

Does stack trace in full debug mode show something useful?