Speicherleaks TMemoryStream in einem Objekt

[Ykcim]

Hallo Zusammen,
ich habe meine Client-Server App massiv umgebaut und dabei soviele Speicherleaks geschaffen, dass die Anwendung wegen überfülltem Speicher nach 1-2 Stunden abstürzt.
Allerdings finde ich den Fehler nicht.
Ich versuche mich gerade in FastMM4 einzuarbeiten.

Aber mal eine grundsätzliche Frage:
Werden TMemoryStreams, die ich in einem Objekt definiere, freigegeben, wenn ich das Objekt freigebe?

Beispiel:
Definition

Delphi-Quellcode:

Type
   TMxSQL = class
      fColsSetMain: TCols;
      fRowsSetMain: TRows;
      fStreamSetMain: TMemoryStream;
      fColsSetBSC: TCols;
      fRowsSetBSC: TRows;
      fStreamSetBSC: TMemoryStream;
   private
      { Private-Deklarationen }
   public
      { Public-Deklarationen }
      property ColsSetMain: TCols read fColsSetMain write fColsSetMain;
      property RowsSetMain: TRows read fRowsSetMain write fRowsSetMain;
      property ColsSetBSC: TCols read fColsSetBSC write fColsSetBSC;
      property RowsSetBSC: TRows read fRowsSetBSC write fRowsSetBSC;
      property StreamSetMain: TMemoryStream read fStreamSetMain write fStreamSetMain;
      property StreamSetBSC: TMemoryStream read fStreamSetBSC write fStreamSetBSC;
      constructor Create(GetSets: boolean = true);

Aufruf aus der Form

Delphi-Quellcode:

procedure TFrm_Main_BSC.FormShow(Sender: TObject);
var   I: integer;
      SpecialStart: boolean;
      MxSQL: TMxSQL;
begin
   Try
      MxSQL:= TMxSQL.Create;
      Try
       ...
      Finally
         MxSQL.Free;
      End;

Der Constructor

Delphi-Quellcode:

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

Die Datenbank-Abfrage:

Delphi-Quellcode:

procedure TMxSQL.GetSettings(Tabelle: string);
var   LClient: TxDataClient;
      LService: IDBService;
      Logic: TLogic;
begin
   LClient := TXDataClient.Create;
   Logic:= TLogic.Create;
   Try
      LClient.Uri:= DB_Unit.xData_Connect.URL;
      LService:= LClient.Service<IDBService>;
      if Tabelle = 'hlp_properties_bsc' then begin
         fStreamSetBSC:=LService.Properties_BSC_Select as TMemoryStream;
         fStreamSetBSC.Position:=0;
         Logic.StreamToRows(fStreamSetBSC, fColsSetBSC, fRowsSetBSC);
      end
      else if Tabelle = 'hlp_properties' then begin
         fStreamSetMain:=LService.Properties_Select as TMemoryStream;
         fStreamSetMain.Position:= 0;
         Logic.StreamToRows(fStreamSetMain, fColsSetMain, fRowsSetMain);
      end;
   Finally
      LClient.Free;
      Logic.Free;
   end;
end;

Hierbei passiert irgendwo neben vielen anderen Stellen eine Speicherleak.

Das ist die Zusammenfassung aus dem Report von FastMM4:

Zitat:

--------------------------------2023/12/22 15:07:18--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

21 - 36 bytes: System.Classes.TBytesStream x 9, System.Classes.TMemoryStream x 20
1509 - 1668 bytes: Unknown x 1

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 37796, 8356, 37796, 37796, 41124, 7844, 8356, 7332

Müsste ich fStreamSetMain und fStreamSetBSC separat vor MxSQL.Free freigeben oder werden die mit freigegeben?

Vielen Dank
Patrick

[himitsu]

Du erstellst etwas im Constructor, was sich nicht selbst freigibt,
warum fehlt dann dein Destructor?

Wo ist das

Delphi-Quellcode:

inherited Create;

?

Und wieso gibt es ein WRITE bei den Streams? Die werden intern erstellt, also was wird wohl passieren, wenn dort wirklich mal jemand etwas zuweist?

[Ykcim]

Ok, da hast Du direkt die Lücken getroffen...:oops:

Zitat:

Und wieso gibt es ein WRITE bei den Streams? Die werden intern erstellt, also was wird wohl passieren, wenn dort wirklich mal jemand etwas zuweist?

Stimmt, macht keinen Sinn, aber ich gebe eigentlich bei properties immer read und write an. Aber so wäre es richtig:

Delphi-Quellcode:

property StreamSetMain: TMemoryStream read fStreamSetMain;
property StreamSetBSC: TMemoryStream read fStreamSetBSC;

Ich nehme an, die korrekte Definition des Contructors sähe so aus:

Delphi-Quellcode:

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

Und dann müsste ich den Destructor auch anpassen, oder?

Delphi-Quellcode:

destructor TMxSQL.Free;
begin
   fStreamSetMain.Free;
   fStreamSetBSC.Free;
   Inherited Free;
end;

Aber wenn ich es so mache, crasht die App sofort - das scheint nicht der richtige Weg zu sein...

Hast Du einen Tip für mich?

[Gausi]

Der Destructor muss

Delphi-Quellcode:

Destroy

heißen, nicht Free.

[hoika]

Hallo,
im Constructor wird der TMemoryStream nicht immer erzeugt

if GetSets then begin
fStreamSetMain:= TMemoryStream.Create;

in Destructor aber immer freigegeben
fStreamSetMain.Free;

Besser wäre FreeAndNil(fStreamSetMain)

[Ykcim]

Ich habe es jetzt so angepasst und es gibt zumindest keinen Crash mehr...

Delphi-Quellcode:

destructor Destroy; override;

...

destructor TMxSQL.Destroy ;
begin
   FreeAndNil(fStreamSetMain);
   FreeAndNil(fStreamSetBSC);
   SetLength(fColsSetMain, 0);
   SetLength(fRowsSetMain, 0, 0);
   SetLength(fColsSetBSC, 0);
   SetLength(fRowsSetBSC, 0, 0);
   Inherited;
end;

Aufruf:

Delphi-Quellcode:

MxSQL.Free;

Aber das Speicherleak ist immernoch katastrophal...

Zitat:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

21 - 36 bytes: System.Classes.TBytesStream x 3, System.Classes.TMemoryStream x 19
37 - 52 bytes: System.Classes.TMemoryStream x 1
1509 - 1668 bytes: Unknown x 1

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 41124, 7332

Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".

[hoika]

Hallo,
naja, Katastrophe ist es nicht. ;)

Vorschlag
Definiere abgeleitete Klassen für Deine TMemoryStreams.

Also so:

Delphi-Quellcode:

TMemoryStream_StreamSetMain = class(TMemoryStream)</Delphi>

und dann

Delphi-Quellcode:

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: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