Speicherleaks TMemoryStream in einem Objekt

[hoika]

Hallo,
naja, Katastrophe ist es nicht.

Vorschlag
Definiere abgeleitete Klassen für Deine TMemoryStreams.

Also so:
TMemoryStream_StreamSetMain = class(TMemoryStream)</Delphi> und dann

fStreamSetMain:= TMemoryStream_StreamSetMain.Create; usw.


Das schöne ist, Du siehst im FastMM4-Log den Namen des MemStreams, der erzeugt, und nicht freigegeben wird.


PS:
wird nicht sogar die Zeile angezeigt, wo der Stream erzeugt wurde???

[Ykcim]

Zitat:

naja, Katastrophe ist es nicht.

Das sind die Leaks, die nur beim Programmstart entstehen...


Der Vorschlag mit der abgeleitet Klasse ist glaube ich gar nicht nötig, denn ich kann in der Speicherbeschreibung sehen, um welche Tabelle es sich handelt:

Zitat:

A memory block has been leaked. The size is: 7332

This block was allocated by thread 0x2F40, and the stack trace (return addresses) at the time was:
4072A5 [System.pas][System][@ReallocMem$qqrrpvi][5035]
40F883 [System.pas][System][DynArraySetLength$qqrrpvpvipi][36568]
177AF6B [Sparkle.WinHttp.Engine.pas][Sparkle.WinHttp.Engine][Winhttp.Engine.TWinHttpResponse.GetContentLength][345]
40F9EA [System.pas][System][@DynArraySetLength$qqrv][36672]
177C59F [Sparkle.Http.Engine.pas][Sparkle.Http.Engine][Http.Engine.THttpResponse.GetContentAsBytes][292]
1778D97 [Sparkle.WinHttp.Api.pas][Sparkle.WinHttp.Api][Winhttp.Api.WinHttpCheck$qqrox20System.UnicodeStri ng][705]
177B01A [Sparkle.WinHttp.Engine.pas][Sparkle.WinHttp.Engine][Winhttp.Engine.TWinHttpResponse.GetStatusCode][359]
18E1DBA [XData.Client.pas][XData.Client][Client.TXDataInvoker.Execute][996]
18E03BC [XData.Client.pas][XData.Client][Client.TXDataClient.GetServiceInterface_ActRec._0_ Body$qqrp23System.Rtti.TRttiMethodx42System.%Dynam icArray$18System.Rtti.TValue%r18System.Rtti.TValue][505]
4F58D0 [System.Rtti.pas][System.Rtti][Rtti.TVirtualInterface.RawCallback][12170]
4F5565 [System.Rtti.pas][System.Rtti][Rtti.TVirtualInterface.Create_1__ActRec._0_Body$qq rpvx42System.%DynamicArray$18System.Rtti.TValue%r1 8System.Rtti.TValue][12135]

The block is currently used for an object of class: Unknown

The allocation number is: 380836

Current memory dump of 256 bytes starting at pointer address 7F2B10C0:
01 00 00 00 F7 19 00 00 7B 22 46 44 42 53 22 3A 7B 22 56 65 72 73 69 6F 6E 22 3A 31 35 2C 22 4D
61 6E 61 67 65 72 22 3A 7B 22 55 70 64 61 74 65 73 52 65 67 69 73 74 72 79 22 3A 74 72 75 65 2C
22 54 61 62 6C 65 4C 69 73 74 22 3A 5B 7B 22 63 6C 61 73 73 22 3A 22 54 61 62 6C 65 22 2C 22 4E
61 6D 65 22 3A 22 68 6C 70 5F 70 72 6F 70 65 72 74 69 65 73 5F 62 73 63 22 2C 22 53 6F 75 72 63
65 4E 61 6D 65 22 3A 22 68 6C 70 5F 70 72 6F 70 65 72 74 69 65 73 5F 62 73 63 22 2C 22 53 6F 75
72 63 65 49 44 22 3A 31 2C 22 54 61 62 49 44 22 3A 30 2C 22 45 6E 66 6F 72 63 65 43 6F 6E 73 74
72 61 69 6E 74 73 22 3A 66 61 6C 73 65 2C 22 4D 69 6E 69 6D 75 6D 43 61 70 61 63 69 74 79 22 3A
35 30 2C 22 43 6F 6C 75 6D 6E 4C 69 73 74 22 3A 5B 7B 22 63 6C 61 73 73 22 3A 22 43 6F 6C 75 6D
. . . . ÷ . . . { " F D B S " : { " V e r s i o n " : 1 5 , " M
a n a g e r " : { " U p d a t e s R e g i s t r y " : t r u e ,
" T a b l e L i s t " : [ { " c l a s s " : " T a b l e " , " N
a m e " : " h l p _ p r o p e r t i e s _ b s c " , " S o u r c
e N a m e " : " h l p _ p r o p e r t i e s _ b s c " , " S o u
r c e I D " : 1 , " T a b I D " : 0 , " E n f o r c e C o n s t
r a i n t s " : f a l s e , " M i n i m u m C a p a c i t y " :
5 0 , " C o l u m n L i s t " : [ { " c l a s s " : " C o l u m

Aber in den Dateien, die darüber erwähnt werden, ist keine selbstdefinierte...

Aktuell habe ich noch das Problem, dass mit dem angepasst Destructor die Applikation bei einer MutiThread Procedure abstüzt.
Habe sie schon angepasst, aber ohne Erfolg:

Delphi-Quellcode:

constructor TMxSQL.Create(GetSets: boolean);
begin
   inherited Create;
   fStreamCreated:= false;
   if GetSets then begin
      fStreamCreated:= true;
      fStreamSetMain:= TMemoryStream.Create;
      GetSettings('hlp_properties');
      fStreamSetBSC:= TMemoryStream.Create;
      GetSettings('hlp_properties_bsc');
   end;
end;

destructor TMxSQL.Destroy ;
begin
   if fStreamCreated then begin
      if fStreamSetMain <> nil then
         FreeAndNil(fStreamSetMain);
      if fStreamSetBSC <> nil then
         FreeAndNil(fStreamSetBSC);
      SetLength(fColsSetMain, 0);
      SetLength(fRowsSetMain, 0, 0);
      SetLength(fColsSetBSC, 0);
      SetLength(fRowsSetBSC, 0, 0);
   end;
   Inherited;
end;

Zitat:

FastMM has detected an attempt to call a virtual methode on a freed object.

Wenn ich den Destructor auskommentiere, entsteht der Fehler nicht...

[Ykcim]

Vergesst des Crash - habe den Fehler gefunden...

Hatte gestern testweise die Streams manuell freigegebe:

Delphi-Quellcode:

      MxSQL.StreamSetMain.Free;
      MxSQL.StreamSetBSC.Free;
      MxSQL.Free;

Dann muss es mit dem Destructor ja crashen...

[Ykcim]

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

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

[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 von Ykcim:

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

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.

[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 (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 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.

[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.