search

pleriche / FastMM4

A memory manager for Delphi and C++ Builder with powerful debugging facilities
447 stars 158 forks source link

Weak references crash the application on exit when used with FastMM #63

Open obones opened 6 years ago

obones commented 6 years ago

I have a sample application here, compiled with Tokyo 10.2.3, where two interface implementations reference each other and to avoid a leak, I use the [Weak] attribute. However, when used with FastMM, I get the "FastMM has detected a FreeMem call after FastMM was uninstalled" error message upon closing the application. This happens with the latest FastMM GIT content taken from this repository.

Looking around here, I saw issues #41 and #18 which both refer to RSP-16796 : https://quality.embarcadero.com/browse/RSP-16796

However, that one tells me that it was fixed by Tokyo 10.2.2 and so I believe I should not be encountering it.

Have I stumbled onto something new? If yes, is this really an issue in FastMM itself? To me it looks like it is not and rather a new issue in Tokyo. What do you think?

As I cannot upload zip files on GitHub, I have put the content here: https://gist.github.com/obones/abbe67b58526d6decb425de202b37aef

Many thanks for your comments.

pleriche commented 5 years ago

Hi Olivier,

You should disable the "DetectMMOperationsAfterUninstall" option if you are using weak references, since the default memory manager is invoked in order to free the TInstHashMap used by the weak reference mechanism, but only after FastMM4 is already uninstalled. In this situation the calling of FreeMem after FastMM4 has been uninstalled is thus not an error condition.

Best regards, Pierre

obones commented 5 years ago

Thanks, but to me DetectMMOperationsAfterUninstall is only a workaround. I think it's an issue in the RTL itself, once again, that does not take into account third party memory managers. I believe that I should report this to Embarcadero in QP. What do you think?

pleriche commented 5 years ago

This is definitely a flaw in the RTL. It currently relies on any 3rd party memory manager that is installed to uninstall itself during its unit finalization and then restore the original memory manager. This is a new requirement, and may be tricky to comply with in some cases (e.g. when multiple handlers are chained together).

I think filing a QP report is appropriate. Thanks.

obones commented 5 years ago

Done: https://quality.embarcadero.com/browse/RSP-22897

We'll see how it is handled

GunSmoker commented 4 years ago

This is fixed in 10.4, so this ticket should probably be closed.