Jump to content
Sue King

FastMM4 and False Positives

Recommended Posts

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

 

 

Share this post


Link to post

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

 

FastMM4 doesn't get this wrong. 

  • Haha 7

Share this post


Link to post

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

 

@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.

Share this post


Link to post

@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.

Share this post


Link to post

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 by Stefan Glienke
  • Like 1

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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 by Dalija Prasnikar
  • Like 2

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
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.

  • Like 3
  • Haha 1

Share this post


Link to post
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 by Fr0sT.Brutal
tip added

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×