Speicherleaks TMemoryStream in einem Objekt

[Ykcim]

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

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