Hallo,

leite ich Klassen von TInterfacedPersistent ab, meldet mir FastMM, dass diese Klasse ein Speicherleck verursacht.
Folgendes Beispiel:

zusammenfalten · markieren

Delphi-Quellcode:

unit ClassesSB;

interface

uses SysUtils, Classes;

type
  ISBParam = interface(IInterface)
    ['{3A2C91E1-9935-436B-BCCE-489F0615F5D1}']
    function GetValue(const sParamFieldName : string; const iParamType : integer) : string;
  end;

  TSBParamClass = class of TSBParam;

  TSBParam = class(TInterfacedPersistent, ISBParam)
  //TSBParam = class(TInterfacedObject, ISBParam)
  private
  public
    function GetValue(const sParamFieldName : string; const iParamType : integer) : string; virtual;
  end;

  TSBParamTest = class(TSBParam)
  private
  public
    function GetValue(const sParamFieldName : string; const iParamType : integer) : string; override;
  end;

implementation

{ TSBParam }

function TSBParam.GetValue(const sParamFieldName: string;
  const iParamType: integer): string;
begin
  Result := '';
end;

{ TSBParamTest }

function TSBParamTest.GetValue(const sParamFieldName: string;
  const iParamType: integer): string;
begin
  Result := Format('Param=%s Type=%d', [sParamFieldName, iParamType]);
end;

initialization

  RegisterClasses([TSBParamTest]);


end.

Und so wird es verwendet:

markieren

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var sbParam : ISBParam;
begin
  sbParam := TSBParamClass(FindClass('TSBParamTest')).Create;
  //sbParam := TSBParamTest.Create;
  ShowMessage(sbParam.GetValue('FieldName', 1));
end;

Nutze ich TInterfacedObject als Basisklasse (Kommentare), ist FastMM zufrieden. Allerdings hatte ich vor, die Klassen aus dem Namen als Text zu erzeugen (die Klassennamen sind extern gespeichert), und FindClass arbeitet nur mit Derivaten von TPersistentClass.

Sicher wäre es ein Wordaround, das FindClass mit einer eigenen Listenklasse nachzubilden - aber den Aufwand würde ich mir gern sparen. Ausserdem interessiert es mich, ob wirklich ein Speicherleck entsteht oder FastMM hier eine Falschmeldung produziert.

Ich kann es nicht beweisen, aber ich vermute mal ins blaue, dass TInterfacedPersistent die Referenzzählung aushebelt. Produziert folgender Code ein Leck?

markieren

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var sbParam : ISBParam; temp: TSBParamClass;
begin
  temp := TSBParamClass(FindClass('TSBParamTest')).Create;
  sbParam := temp;
  //sbParam := TSBParamTest.Create;
  ShowMessage(sbParam.GetValue('FieldName', 1));
  temp.Free;
end;

Es gibt beim temp.Free eine Schutzverletzung - ist das eventuell ein Indiz dafür, dass FastMM eine Speicherleck-Falschmeldung produziert?

Args! Ich sollte nicht so spät noch Fragen beantworten... Das sollte natürlich TSBParam in der Variablendeklaration heißen, nicht TSBParamClass *schämt sich in grund und boden*

Da hat mich schon der Compiler drauf aufmerksam gemacht, das war also nicht die Ursache für die Schutzverletzung, die Variablendeklaration hatte ich berichtigt.

Zitat:

Ich sollte nicht so spät noch Fragen beantworten...

Spät? Ich finds eher früh

Zitat von squetk:

Spät? Ich finds eher früh

Sag das mir, so ich seit Wochen nich mehr richtig und seit gestern garnich mehr schlafen kann.. Aber zum Thema: wenn es selbst bei einer richtigen Deklaration der Variablen eine Schutzverletzung gibt, würde ich diese Konstellation zum einen mit einem anderen Memorymanager ausprobieren (sollte das selbe Ergebnis liefern) und in einem anderen Test die Interfaces weglassen. Wie dein Leck zustande kommt, entzieht sich meiner Erkenntnis.. Und die AV deutet auf einen schweren Fehler in einem anderen Programmteil hin. Hast du eventuell Destroy überschrieben und inherited nicht drin? Oder noch schlimmer, Free redeklariert?

Nein - solch schlimme Sachen habe ich nicht gemacht. Alles was ich gecodet habe, ist im ersten Beitrag zu sehen - ganz harmlos.
Sobald ich statt TInterfacedPersistent TInterfacedObject verwende, habe ich ja das gewünschte Ergebnis. Dann kann ich aber FindClass nicht nutzen.
Ich habe mal in den Sourcen nachgeschaut (Classes.pas), dort werden die Methoden _AddRef etc. bei TInterfacedPersistent anders implementiert als bei TInterfacedObject. Merkwürdig.

Also wie vermutet, die Referenzzählung wird ausgehebelt.. Was in dem Fall das beste Vorgehen ist kann ich nicht sagen, aber wenn du auf die Referenzzählung angewiesen bist, könntest du versuchsweise die Implementation aus TInterfacedObject in deine Basisklasse packen (und eventuell dort behalten).

Also eine Klasse von TInterfacedPersistent ableiten und dann das Referenz-Handling von TInterfacedPersistent mit der Implementation von TInterfacedObject überschreiben?
Klingt nicht übel.
Mal schaun ob das klappt.

Komisch: Ich habe eine Klasse TPatchInterfacedPersistent von TInterfacedPersistent abgeleitet und die _AddRef und _Release-Methoden und alle weiteren mit der Implementation von TInterfacedObject überschrieben und die das Interface implementierenden Klassen davon abgeleitet - trotzdem kommt es zum Speicherleck.

Da scheint ein anderes Problem in TInterfacedPersistent verborgen zu sein.

Ich werde wohl das Handtuch schmeissen und eine eigene Listenklasse coden, die mir die FindClass-Funktionalität liefert. Dann können meine implementierenden Klassen von TInterfacedObject abgeleitet sein und es herrscht eitel Sonnenschein.