Der Ablauf ist doch folgender
- Erstelle Frame
- Habe interface-basierte Referenz auf das Frame-Objekt in einem Objekt "X"
- Zerstöre Frame
- Habe weiterhin interface-basierte Referenz auf das Frame-Objekt
- Zerstöre Objekt "X"
- Interface-basierte Referenz wird genullt, versucht Referenzzähler auf den
mittlerweile zerstörten Frame zu verringern (also die Methode _Release() aufrufen)
Ohne FastMM kommt hier zur Laufzeit, denke ich, aus einem von zwei Gründen keine
Exception- Wenn die Anwendung abgeräumt wird ist der Standard-Speichermanager relativ großzügig was das Herunterschlucken von AVs angeht. Zumindest kommt es mir so vor
- Wenn er _Release() auf dem zerstörten Frame aufrufen will bemerkt er nichts ungewöhnliches. Alles klappt wie es soll. Kein Grund sich zu beschweren. Bei FastMM hingegen gibt es eine Einstellung dass beim Zerstören eines Objekts sein gesamter Speicher mit irgendeinem Muster komplett überschrieben wird. Somit ist kein "es könnte noch klappen" mehr möglich, sondern das Aufrufen einer Methode auf einem toten Objekt geht garantiert schief. Das ist bewusst gemacht um solche Fehler zu finden.
Ab Delphi 10.1 Berlin könnte man das Problem ganz gut mit dem [weak]-Attribut angehen, oder? Ich habe mich damit immer noch nicht befasst
