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

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

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1532089)

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

[QuickAndDirty]

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

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1532095)

Weil Pascal/Delphi "objektorientiert" ist :wink:

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz. 8-)

Zitat:

Zitat von QuickAndDirty (Beitrag 1532090)

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.

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1532109)

Zitat:

Zitat von himitsu (Beitrag 1532095)

Weil Pascal/Delphi "objektorientiert" ist :wink:

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz. 8-)

Zitat:

Zitat von QuickAndDirty (Beitrag 1532090)

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.

Es hat trotzdem einen Vorteil wenn man "Just-In-Case" für all diese basic-klassen ein Interface hätte welches sie auch implementieren...
Im Falle von tDatabase wäre es eine NICHT Arc implementierung, aber so hätte man trotzdem noch Möglichkeiten was Auslagerung in DLLs und Reduzierung von Abhängigkeiten betrifft.

[himitsu]

Das Problem ist halt, dass man nicht-referenzgezählte Objekt-Instanzen und Interfaces niemals gleichzeitig auf das "selbe" Objekt haben darf/sollte.

Bzw. bei TComponent ist es "standardmäßig" so, dass optional anhängbare Interfaces nicht referenzgezählt sind.
Jene sollte/darf man somit auch immer nur kurz benutzen und die Interface-Instanz sofort wieder freigeben.
Da hier ausschließich das Objekt die Speicherverwaltung übernimmt, also Free, der Owner, sowie auch der Parent (hat sich Delphi leider von der GDI abgeguckt).

Die Interface-Refrenz wird bei TComponent-Nachfahren also "ungültig", wenn das Objekt freigegeben wird.
Ein NIL zuweisen geht danach dann auch nicht mehr, sowie wenn die Variable aus dem Scope rausläuft, da es versuchen würde IInterface._Release auszuführen, was aber nicht mehr ginge.
Hier sollte man dann am Besten mit [Weak]-Referenzen arbeiten (was aber fast niemand tut).

Hätte man dagegen ein referenzgezähltes Interface, dann würden Jene das Objekt freigeben und die Objekt-Referenzen wären plötzlich alle ungültig.

Zusammen mit ARC wäre so ein Mischbetrieb aber möglich. (wobei ich dennoch froh bin, dass ARC wieder gestorben ist, weil es andere konzeptionelle Nachteile hatte)

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1532112)

(wobei ich dennoch froh bin, dass ARC wieder gestorben ist, weil es andere konzeptionelle Nachteile hatte)

Ja, ARC bedeutet alle Nachteile einer GC aber ohne die schwerer wiegenden Vorteile einer GC .

[Ykcim]

Hallo Zusammen,

ich nutze Delphi seit ca. 15 Jahren hobbymäßig... Aber ab #Post19 brauche ich ein Wörterbuch :oops:

Ich werde in den nächsten Wochen Zuhause die Programmgruppe neu aufbauen und mir das Wörterbuch deneben legen. :lol:

Vielen Dank für die vielen Anregungen, ich werde berichten!

LG Patrick

[stahli]

Zu Interfaces habe ich mal ein paar Infos zusammengestellt: https://www.delphipraxis.net/183702-...-factorys.html