FastMM und aktuelles Delphi

[Der schöne Günther]

Danke für's Ausprobieren. Ich lüge aber nicht.

Embarcadero® RAD Studio 10 Seattle Version 23.0.21418.4207

Mit XE7 kein Problem. Mit 10.1 Berlin kein Problem. Nur 10 Seattle.

Ich habe es mal als Testprojekt angehängt, habe ich alles richtig gemacht?

[Stevie]

Zitat von Der schöne Günther:

Ich lüge aber nicht.

Hab ich auch nicht behauptet - kann es aber immer noch nicht nachstellen - habe Seattle mit Subscription Update 1.

[Der schöne Günther]

Komisch, dann ist mein PC wohl kaputt. Ist auch halb so wild, XE7 und 10.1 gehen ja. Vielen Dank fur's Mitfiebern

[Headbucket]

Hallo zusammen,

ich habe zZ ein ähnliches Problem mit der Verwendung von FastMM in Verbindung mit Frames, welche ein Interface implementieren:

Delphi-Quellcode:

type
  TMyFrame = class(TFrame, IMyInterface)
    lbl1: TLabel;
  private
    { Private-Deklarationen }
  public
    procedure MyInterfaceMethode;
  end;

Ein kleines Testprojekt habe ich angehängt. Beim Beenden der Anwendung bekomme ich eine access violation mit folgendem Stack:

Code:

System._IntfClear(???)
:0040d998 @IntfClear + $10
System.TObject.Free
System.Classes.TComponent.DestroyComponents
Vcl.Forms.DoneApplication
System.SysUtils.DoExitProc
System._Halt0

Ohne FastMM geht alles und auch sonst verwende ich FastMM in sämtlichen Projekten. Aber mit Frames und Interfaces habe ich Probleme... .
Liegt der Fehler bei mir? Falls nicht: Wie kann ich die access violation abstellen? Die Hinweise hier im Thread halfen leider nicht.

Grüße
Headbucket

[Bernhard Geyer]

Zitat von Headbucket:

Hallo zusammen,

ich habe zZ ein ähnliches Problem mit der Verwendung von FastMM in Verbindung mit Frames, welche ein Interface implementieren:

Ich vermute du musst die Refernzzählung deaktivieren.
Ansonsten hast du u.U. doppelte Freigabe. Einerseits über den Parent/owner und andererseits über das Interface.

[Headbucket]

Das war auch mein erster Gedanke.

Mein Frame ist ja aber von TComponent abgeleitet. Wird dort nicht so oder so die Referenzzählung deaktiviert?
Ansonsten wäre ich über Hinweise dankbar, wie man diese abschaltet

Und was hat FastMM damit zu tun? Wenn das ganze doppelt freigegeben wird, dann sollte doch IMMER ein Fehler kommen und nicht nur mit FastMM.

Danke aber schonmal für die Antwort!

Grüße

[Der schöne Günther]

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

1. 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
2. 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