Speicherleaks TMemoryStream in einem Objekt

[Mavarik]

Zitat von Ykcim:

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

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

Ob Clear und Add oder nur "ein" Text:= ist Geschmackssache.
PS: '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 von Ykcim:

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.

[QuickAndDirty]

Zitat von 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.

Warum wurde TStream nicht gleich als Interface umgesetzt?

[himitsu]

Weil Pascal/Delphi "objektorientiert" ist

[QuickAndDirty]

Ich dachte interfaces/traits/behaviors gehören zum OO Baukasten dazu.

[jaenicke]

Zitat von himitsu:

Weil Pascal/Delphi "objektorientiert" ist

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz.

Zitat von QuickAndDirty:

Warum wurde TStream nicht gleich als Interface umgesetzt?

Das wäre sicherlich an einigen Stellen wünschenswert (TList, TDictionary, TStream, TDataset, ...), aber wenn dann jemand diese Klassen als Objektreferenzen einsetzt und irgendwo aus Versehen als Interface übergibt, wäre das doof. Insofern ist es schon auch schwierig, wenn solche Klassen auch als Interface angeboten würden. Und nur als Interface wäre wieder u.a. ein Performancethema und nachträglich kaum machbar.