Speicherleaks TMemoryStream in einem Objekt

[jaenicke]

Wenn du mit Klassen arbeitest (wie hier), wird eine Referenz, also ein Pointer, auf das Objekt geliefert.

Zeig doch einfach mal, wie du aktuell damit arbeitest.

[peterbelow]

Zitat:

Zitat von Ykcim (Beitrag 1531117)

So, ich habe jetzt mal ein bißchen weiter ausprobiert und komme zu einer Frage, bei der ich Euch wahrscheinlich bis hierhin lachen höre:duck:

Wenn ich eine Function habe, die als Rückgabewert einen Stream hat, wird dann der Streaminhalt oder nur der Pointer zurückgegeben?

Ich habe bislang in der aufrufenden Procedure immer eine Variable vom Type T(Memory)Stream created, ihr die Funktion zugewiesen und am Ende der Procedure freigegeben. Aber wenn nur der Pointer übergeben wird, darf ich den Stream in der aufrufenden Procedure gar nicht createn, oder? Der würde ja dann im nirgendwo verschwinden...
Und dann wäre e logisch, warum ich den Stream, obwohl an Result übergeben, nicht free setzen darf.

Ist das so, dann muss ich einiges überdenken...

LG Patrick

Wie Sebastian sagte gibt die Funktion eine Referenz (Pointer) auf das Objekt zurück.

Generell ist so eine Funktion problematisch vom Design her, da nicht klar ist, wer denn nun die Lebensdauer des zurückgegebenen Objektes verwaltet.

Erzeugt die Funktion das Objekt und der Caller muss es freigeben? Dann sollte die Funktion einen Namen haben, der das klar macht: CreateXYZ z. B. In einem solchen Fall ziehe ich es vor, statt einer Function eine Procedure mit einem const Parameter zu verwenden, dem der Caller das von ihm erzeugte Objekt übergibt. Dann ist klar, wer sich drum kümmern muss.

Gibt die Funktion eine Referenz auf ein existierendes Objekt zurück, dessen Lebenszeit anderswo verwaltet wird? Dann darf der Caller es natürlich nicht freigeben und die Funktion sollte z. B. GetXYZ heißen.

Das ganze Problem läßt sich entschärfen, wenn man konsequent mit Interface-Referenzen anstatt mit Objektreferenzen arbeitet. Damit wird die Lebenszeit per reference counting automatisch verwaltet und man muss sich nicht selbst drum kümmern. Dafür hat man dann andere Probleme an der Backe, wie zirkuläre Referenzen zwischen Objekten via Interfaces die den reference count nie auf 0 sinken lassen. :wink:

[Ykcim]

Hallo Zusammen,

vielen Dank für die Erklärungen. Ich bin das Projekt gerade mal überflogen und in dem meisten Fällen habe ich eine procedure verwendet, wo der Stream übergeben wurde und wo klar ist, wer freigeben muss. Aber leider habe ich auch solche Konstellationen:

Delphi-Quellcode:

function TDBService.Get_ProduktReport_General (Kunde: string; Von, Bis: TDate): TStream;
var   MxSQL: TMxSQL;
      LStream: TMemoryStream;
begin
   MxSQL := TMxSQL.Create(false);
   LStream := TMemoryStream.Create;
   Try
      LStream := MxSQL.GetF_Report_Produkte_General(Kunde, Von, Bis);
      Logic_Main.FehlerProzedure := 'Get_ProduktReport_General 2';
      Result:= LStream;
   Finally
      MxSQL.Free;
   End;
end;

Hier wird ein Stream erstellt, der aber nicht übergeben wird.

Delphi-Quellcode:

function TMxSQL.GetF_Report_Produkte_General(Kunde: string; Von, Bis: TDate): TMemoryStream;
var   Logic: TLogic;
      MsQuery: TFDQuery;
      MyQuery: TFDQuery;
      MyCols, MsCols: TCols;
      MyRows, MsRows: TRows;
      VArtikel: string;
      I: integer;
      LStream: TMemoryStream;
      oConn_BM: TFDConnection;
      oConn_MySQL: TFDConnection;
begin
   Logic := TLogic.create;
   LStream := TMemoryStream.Create;
   try
      Logic.Set_Query_FDMngr2(MyQuery, oConn_MySQL, 'BDHMySQL');
      MyQuery.SQL.Clear;
      MyQuery.sql.Add('select wert from hlp_properties '+
                      'where einstellung = :VArtikel');
      MyQuery.ParamByName('VArtikel').asstring := 'VArtikel_' + Kunde;
      ExecQuery(MyQuery, MyCols, MyRows, 0);
      for I := 0 to Length(MyRows[0]) -1 do begin
         if I = 0  then
            VArtikel := MyRows[0,I]
         else
            VArtikel := VArtikel + ', ' + MyRows[0,I];
      end;
      Logic.Set_Query_FDMngr2(MsQuery, oConn_BM, 'BDHBM');
      MsQuery.SQL.Clear;
      MsQuery.sql.Add('SELECT format(bstlyn__.vrz__dat,' + QuotedStr('dd.MM.yyyy') + ') AS Lieferdatum, '+
                              'bstlyn__.bsbn_kla as Bestellnummer, '+
                              'concat(knp__vnm, ' + QuotedStr(' ') + ', knp__nam) AS Besteller, '+
                              'bstlyn__.zynrefkl as ArtNr, '+
                              'bstlyn__.afg_oms1 as Bezeichnung, '+
                              'bstlyn__.l_aantal as Liefermenge, '+
                              'bstlyn__.lbn__ref as Lieferschein, '+
                              'konper__.straat__ as Strasse, '+
                              'konper__.post_ref as PLZ, '+
                              'konper__.postnaam as Ort, '+
                              'konper__.land_ref as Land '+
                      'FROM bstlyn__ '+
                      'LEFT JOIN konper__ ON konper__.lok__ref = bstlyn__.lok__ref '+
                      '    AND konper__.knp__ref = bstlyn__.knplkref '+
                      'LEFT JOIN bstext__ ON bstext__.lyn__ref = bstlyn__.lyn__ref '+
                      'LEFT JOIN wafgfl__ ON wafgfl__.lyn__ref = bstlyn__.lyn__ref '+
                      'where l_aantal > 0 '+
                      'and bstlyn__.kla__ref = :KundenNr '+
                      'and bstlyn__.afg__ref not IN ( '+ VArtikel + ') '+
                      'and vrz__dat >= :Von '+
                      'and vrz__dat <= :Bis ');
      MsQuery.ParamByName('Von').AsDate := Von;
      MsQuery.ParamByName('Bis').AsDate := Bis;
      MsQuery.ParamByName('KundenNr').AsString := Kunde;

      ExecQuery(MsQuery, MsCols, MsRows,1);
      if Assigned(LStream) then begin
         LStream := Logic.GridToStream(MsCols, MsRows);
      end;
      Result := LStream;
   finally
      MsQuery.Free;
      MyQuery.Free;
      Logic.Free;
      oConn_BM.Free;
      oConn_MySQL.Free;
   end;
end;

Und hier wird ein weiterer Stream erzeugt.

Ich nehme an, der Pointer des Streams aus der aufrufenden procedure wird von dem Pointer aus der function überschrieben.
Dann würde am Ende der aufrufenden procedure der Stream aus der function beendet werden und der Stream, der in der Procedure erstellt wurde ist eines meiner Speicherleaks, oder?

Also entweder der aufgerufenen function den Stream mitgeben oder den Stream in der aufrufenden procedure nicht erstellen, aber freigeben...

Sehe ich das richtig? Hört sich ein bißchen verwirrt an...

Vielen Dank
Patrick

EDIT: Sehe gerade, dass die aufrufende procedure eine function ist, weil es sich um einen Service handelt, der das Ergebnis an den Client liefert...

[Delphi.Narium]

Dashier ist nicht als nachahmenswert gedacht:

Delphi-Quellcode:

// Die Funktion Get_ProduktReport_General liefert einen Stream zurück:
function TDBService.Get_ProduktReport_General (Kunde: string; Von, Bis: TDate): TStream;
var MxSQL: TMxSQL;
begin
   MxSQL := TMxSQL.Create(false);
   Try
      // Die Funktion GetF_Report_Produkte_General liefert ebenfalls einen Stream zurück:
      Result := MxSQL.GetF_Report_Produkte_General(Kunde, Von, Bis);
      Logic_Main.FehlerProzedure := 'Get_ProduktReport_General 2';
   Finally
      MxSQL.Free;
   End;
end;

Man kann sich damit in der Funktion Get_ProduktReport_General das Erstellen eines Streams schonmal sparen, da Result schon ein Stream ist, benötigt man keinen weiteren Stream als Zwischenschritt, zumal LStream nach dem Erstellen sowieso nicht mehr benötigt wird, sondern einen anderen Stream zugewiesen bekommt.

Beim gesamten Konstrukt sehe ich eine große Chance, Speicherlöcher zu erstellen.

In GetF_Report_Produkte_General wird LStream erstellt. Dann passiert einiges, aber nicht mit LStream. Dann wird geprüft, ob LStream was enhält, was nach dem Create eher wahrscheinlich ist.

Nachdem nun klar ist, dass LStream etwas enthält, wird LStream was anderes zugewiesen (

Delphi-Quellcode:

Logic.GridToStream(MsCols, MsRows);

) Unklar ist, ob der Inhalt von LStream hier irgendeinen Einfluß haben könnte. Tippe mal auf: eher nicht.

Dem erstellten und auf Vorhandensein, aber nicht weiter genutzten, LStream wird also was anderes zugewiesen und das wird dann als Result zurückgegeben.

Bis hierher erscheint mir LStream als absolut überflüssig. Meiner Meinung nach kann LStream vollständig aus der Funktion entfernt werden und aus

Delphi-Quellcode:

if Assigned(LStream) then begin
  LStream := Logic.GridToStream(MsCols, MsRows);
end;
Result := LStream;

könnte

Delphi-Quellcode:

Result := Logic.GridToStream(MsCols, MsRows);

werden. Damit bliebe dann "nur noch" Result als Stream übrig, dessen Freigabe man später vergessen könnte. Die Zahl der möglichen Speicherlöcher könnte / wird durch Weglassen der LStreams in beiden Funktionen jedenfalls verringert werden. Glücklich erscheint mir das Konstrukt insgesamt jedoch nicht.

[himitsu]

Zitat:

Delphi-Quellcode:

if Assigned(LStream) then

Nicht NOT?

Free und FreeAndNil besitzen bereits ein eingebautes if Assigned(Self) then Destroy,
entweder es wird erstellt oder nicht (dann isses NIL, im Destructor), also kann man eigentlich immer einfach direkt Free auffrufen, egal ob Assigned oder nicht. (außer von außen wurden Fremdobjekte reingegeben und diese werden nicht geOwned)
(im Destructor und bei lokalen Variablen verwende ich aber eigentlich nie FreeAndNil, weil schreibfaul und Free per Codevervollständigung kommt ... FreeAndNil ist meistens aber auch unnötig / nicht falsch)

[Mavarik]

Zitat:

Zitat von Ykcim (Beitrag 1531129)

Hallo Zusammen,

Delphi-Quellcode:

function TDBService.Get_ProduktReport_General (Kunde: string; Von, Bis: TDate): TStream;
var   MxSQL: TMxSQL;
      LStream: TMemoryStream;
begin
   MxSQL := TMxSQL.Create(false);
   LStream := TMemoryStream.Create;
   Try
      LStream := MxSQL.GetF_Report_Produkte_General(Kunde, Von, Bis);
      Logic_Main.FehlerProzedure := 'Get_ProduktReport_General 2';
      Result:= LStream;
   Finally
      MxSQL.Free;
   End;
end;

Hier wird ein Stream erstellt, der aber nicht übergeben wird...

Der erzeugte LStream ist schon ein leak, da die Referenz überschrieben wird un somit nie wieder frei gegeben wird.

Wenn Du im Constructor eine bedingte Erzeugung von Objekten hast, solltest Du im Else-Fall die lokale Instance mit NIL belegen, da Objekte nicht managed sind und daher auch nicht mit NIL initialisiert werden. Ein .free kann dann ggf. crashes da eine zufällige Adresse in der instance steht.

Wenn Du viel mit Streams “spielst” solltest Du Dir einen IStream wrapper schreiben.

Mavarik :coder:

PS: Zu Deinem handgeklöppeltem SQL-String sag ich jetzt mal nix - obwohl das sicherlich auch zu Problemen führen kann. Hier solltest Du Dir mal die Verwendung vom Params ansehen.

[Ykcim]

Hallo Zusammen,

die letzten zwei Wochen bin ich nicht dazu gekommen, an dem Thema weiter zu arbeiten. Habe während meines Urlaubs verschiedene Dinge umgebaut, aber bekomme die Speicherprobleme nicht in den Griff. Habe mich entschieden, die Software noch mal neu aufzubauen und Schritt für Schritt die Speicheraktivitäten zu überprüfen. Ich habe zu viele Proceduren mit der falschen Implementierung erstellt (siehe Anmerkung Delphi.Narium). Außerdem wird die Software wesentlich umfangreicher eingesetzt, als damals gedacht, sodass es jetzt Sinn macht, einige Strukturen neu zu definieren... Das wird aber ein paar Wochen dauern, weil ich das nur abends machen kann...

Eure Hinweise, Erklärungen und Anregungen werden ich dabei versuchen mit einfließen zu lassen.

Dazu hätte ich noch zwei Fragen:
@himitsu:
Was ist ein iStream Wrapper?
Und warum "gefällt" Dir mein SQL-Statement nicht - heißt: warum ist es technisch nicht gut erstellt? Ich mache das nämlich immer so...

Vielen Dank
Patrick

[himitsu]

QuotedStr ist nicht für SQL (ja, ich weiß, dass es alle verwenden.
QuotedStr ist für die Syntax der Delphi-Strings, im Quellcode und kennt auch nur dessen Escaping.

Für die Datenbanken sollten/müssten Query-Komponenten eigentlich eine passende Funktion irgendwo besitzen, welche die Syntax des jeweiligen SQL-Textes versteht.

Also erstmal vermute ich nicht, dass er etwas "Neues" meint, was jetzt endlich geht.
MultiLine-Strings :angle:

Ob Clear und Add oder nur "ein" Text:= ist Geschmackssache.
PS:

Delphi-Quellcode:

'SELECT format(bstlyn__.vrz__dat, ''dd.MM.yyyy'' AS Lieferdatum, '+

Und seit Delphi 12 geht nun sowas:

Code:

      MsQuery.SQL.Add('''
        SELECT format(bstlyn__.vrz__dat, 'dd.MM.yyyy') AS Lieferdatum,
          bstlyn__.bsbn_kla AS Bestellnummer,
          concat(knp__vnm, ' ', knp__nam) AS Besteller,
          bstlyn__.zynrefkl AS ArtNr,
          bstlyn__.afg_oms1 AS Bezeichnung,
          bstlyn__.l_aantal AS Liefermenge,
          bstlyn__.lbn__ref AS Lieferschein,
          konper__.straat__ AS Strasse,
          konper__.post_ref AS PLZ,
          konper__.postnaam AS Ort,
          konper__.land_ref AS Land
        FROM bstlyn__
        LEFT JOIN konper__ ON konper__.lok__ref = bstlyn__.lok__ref
          AND konper__.knp__ref = bstlyn__.knplkref
        LEFT JOIN bstext__ ON bstext__.lyn__ref = bstlyn__.lyn__ref
        LEFT JOIN wafgfl__ ON wafgfl__.lyn__ref = bstlyn__.lyn__ref
        WHERE l_aantal > 0
          AND bstlyn__.kla__ref = :KundenNr
          AND bstlyn__.afg__ref not IN (&VArtikel)
          AND vrz__dat >= :Von
          AND vrz__dat <= :Bis 
        ''');
      MsQuery.ParamByName('Von').AsDate := Von;
      MsQuery.ParamByName('Bis').AsDate := Bis;
      MsQuery.ParamByName('KundenNr').AsString := Kunde;
      MsQuery.MacroByName('VArtikel').Value := VArtikel;

(nicht als [DELPHI], da das Forum mit sowas noch Probleme hat und alle führenden Leerzeichen vergisst)


Vermutlich will er aber mehr darauf hinaus, dass es auch andere Möglichkeiten gibt, als "statische" SQLs im Code zu verwenden.
* einmal kann man SQLs auch in andere Dateien (Ressourcen) auslagern, wo es (früher) bessere Möglichkeiten des Schreibens gibt
* oder garkeine Texte, sondern etwas objektorientiertes Selbstgenerierendes
* oder ...

[QuickAndDirty]

Zitat:

Zitat von Ykcim (Beitrag 1532072)

Was ist ein iStream Wrapper?

Interface-Typen können sich selbst freigeben.
Deswegen denke ich das sowas dir helfen könnte...

Delphi-Quellcode:

type

IMemoryStream = interface
  Function GetStream:TMemoryStream;
  procedure SetStream(aValue:TMemoryStream);
end;
TStreamWrapper=Class(TInterfacedObject, IMemoryStream )
private
  fStream:TMemoryStream
Public
  Function GetStream:TMemoryStream;
  procedure SetStream(aValue:TMemoryStream);
  // Hier könnte man noch alle Stream Methoden hinpaken die man selbst oft benutzt
  // die wrappen quasi die methoden vom TMemoyStream, weil sie einfach nur die selbe Methode in FStream aufrufen.
  Constructor Create;Virtual;
  Destructor Destroy;Override;
  Property Stream:TMemoryStream read GetStream write SetStream;
end;
Implementation


Function TStreamWrapper.SetStream(aValue:TMemoryStream);
Begin
  if Assigned(fStream) then
    FreeAndNil(fStream);// ODER Raise Exception.create('Fehler der Wrapper besitzt bereits einen Stream!');
  fStream := aValue;
end;

Function TStreamWrapper.GetStream:TMemoryStream;
Begin
  Result := fStream
end;

Constructor TStreamWrapper.Create;
Begin
  inherited;
  fStream := nil;
end;

Destructor TStreamWrapper.Destroy;
Begin
  if Assigned(fStream) then
    FreeAndNil(fStream);
  inherited;
end;

Statt Streams als Rückgabewert von Funktionen solltest du den Wrapper ausgeben.
Der Wrapper würde den Stream Freigeben wenn keine Variable mehr den Wrapper referenziert. Daher kommt es nicht mehr zu Speicherlecks wenn du den Stream nicht freigibst.
Mann nennt das ARC...RC steht für Referenzählung...
Wichtig ist das NUR der Wrapper den Stream kennt. Sonnst kommt es zwar nicht so Speicherlecks aber zu "use after free" Fehlern.

Man benutzt es so dass man nur IMemorystream referenziert!

Delphi-Quellcode:

var LStream:IMemoryStream := (TStreamWrapper.create as IMemoryStream );
LStream.Stream := TMemoryStream.create;

[himitsu]

Leider ist von Microsoft das IStream nicht kompatibel mit Delphis TStream (von den Methoden her)
und für die Verwendung braucht man ja immernoch das Delphi-Objekt.