pleriche
Weak references crash the application on exit when used with FastMM
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.
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
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?
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.
Done: https://quality.embarcadero.com/browse/RSP-22897
We'll see how it is handled
