Object.Free ruft unter XE5 kein Destroy mehr auf!?

[Shark99]

Ich habe viele Jahre lang Delphi 7 verwendet.

Vor wenigen Monaten bin ich auf XE5 umgestiegen.

Seit geraumer Zeit nutze ich Generics-Listen.

Heute hatte ich das Gefühl dass meine App etwas Speicher leakt, also habe ich FastMM in den Debug Mode aktiviert und hab tatsächlich den Leak (und auch andere die damit zusammenhängen) angezeigt bekommen.

Ich habe eine eigene Listen-Klasse erstellt:

Delphi-Quellcode:

DataList = class(TObjectList<TDataItem>)

Im Create() der Klasse alloziere ich verschiedene Objekte, z.B.

Delphi-Quellcode:

FCryptoLib  := TCryptographicLibrary.Create(nil);

Im Destroy() gebe ich den Speicher wieder frei:

Delphi-Quellcode:

FCryptoLib.Free;

Dachte ich zumindestens bis heute. Wenn eine Liste nicht mehr gebraucht wird dann mache ich ein

Delphi-Quellcode:

myDataList.Free;

Ich hab angenommen dass das Free() -> Destroy() aufruft (und damit den Speicher für die Lib freigibt).

FastMM Debug zeigte mir jedoch dass es nicht der Fall ist und FCryptoLib nicht freigegeben wird.

Wenn ich statt dessen...

Delphi-Quellcode:

myDataList.Destroy;

direkt aufrufe hat FastMM nichts mehr zu meckern.

Ich hab mir also angeschaut was im Free() gemacht wird:

Delphi-Quellcode:

procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
  if Self <> nil then
    Destroy;
{$ENDIF}
end;

Und zu meinem Erschrecken stelle ich fest dass Destroy wirklich nicht mehr aufgerufen wird!

Ich schaute mir die Funktion nochmals unter Delphi 7 an:

Delphi-Quellcode:

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

Und alles noch da wie ich es kannte.

Kann mir bitte jemand erklären wieso das geändert wurde!? Ich würde mal behaupten es gibt mehr Leute wie mich die davon nichts wissen und alles mögliche schön mit .Free() freizugeben versuchen und gleichzeitig ein eigenes Destroy() in Klassen verwenden.

[nahpets]

Ich interpretiere dashier mal so:

Delphi-Quellcode:

procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
  if Self <> nil then
    Destroy;
{$ENDIF}
end;

Es muss irgendwo ein

Delphi-Quellcode:

{$DEFINE AUTOREFCOUNT}

geben und deshalb wird der Quelltext da nicht mit kompiliert.

Das solltest Du mal prüfen und feststellen, ob Du das ändern kannst.

[Shark99]

Kann ich auschliessen (AUTOREFCOUNT ist also default an unter XE5), weil ich es in einem Testprojekt mit nur 20 Zeilen Code getestet habe. Zu der Uses Klausel hab ich nur FastMM und die Generics hinzufügt. In FastMM ist keine Referenz zu AUTOREFCOUNT (mit grep geschaut).

[nahpets]

Wenn das Defaultmäßig an ist, dann wäre aber die Art der Implementierung in den Delphisourcen der Fehler.

Entweder müsste die Definition aufgehoben werden oder die Abfrage auf IFDEF geändert werden.

Einfacher Test:

Delphi-Quellcode:

{$IFDEF AUTOREFCOUNT}
ShowMessage('Definiert');
{$ELSE}
ShowMessage('nicht Definiert');
{$ENDIF}

Was kommt dabei raus?

Meine (unprofessionelle) Fehlerbehebung sähe dann erstmal so aus:

In die eigene Unit kommt am Anfang ein {$UNDEF AUTOREFCOUNT} rein und/oder eventeull in der DPR des Programmes.
Klar muss man vorher schauen, ob und ggfls. welche Nebenwirkungen man damit verursacht, also mal schauen, wo überall AUTOREFCOUNT abgefragt wird.

[himitsu]

ARC ist "aktuell" nur in den mobilen Platformen aktiv, also iOS und Android.
Aber wie der Name schon sagt, gibt da die Speicherverwaltung alles von selber frei, wenn keine Variable mehr auf das Objekt zeigt ... genauso wie es schon immer bei Interfaces der Fall ist.

Hat nur das "Problem" wenn man etwas wirklich genau an der Stelle freigeben will, da muß man dann eben bissl aufpassen, dass alle Variablen genilt werden,
oder TObject.Release.

Zitat:

Zitat von nahpets (Beitrag 1356772)

Meine (unprofessionelle) Fehlerbehebung sähe dann erstmal so aus:

In die eigene Unit kommt am Anfang ein {$UNDEF AUTOREFCOUNT} rein und/oder eventeull in der DPR des Programmes.
Klar muss man vorher schauen, ob und ggfls. welche Nebenwirkungen man damit verursacht, also mal schauen, wo überall AUTOREFCOUNT abgefragt wird.

NEIN.

Das ist erstens ein Compiler-Feature-Define, welches das angibt, was der Compiler macht und nichts was der Entwickler steuern kann/soll.
http://geheimniswelten.de/sonstiges/...piler/#Defines
Also egal ob du es umschreibst, der Compiler bleibt bei seinem Verhalten.
Und das Free interessiert deine Definition sowas von garnicht, da die System.pas erstens nicht neu kompiliert wird und zweitens kommt dein UNDEF dort garnicht an.

[himitsu]

[del]

[nahpets]

Ok, wenn Du das sagst, wird es schon stimmen, kennen die Interna wohl nicht so genau.

Aber wenn ich das richtig verstehe, wird im Free das Destroy nicht aufgerufen, weil es AUTOREFCOUNT gibt. Oder?

[Shark99]

Hab das hier an den Anfang des TestCode gesetzt:

Delphi-Quellcode:

{$IFDEF AUTOREFCOUNT}
  Caption := 'AUTOREFCOUNT ist definiert!';
{$ELSE}
  Caption := 'AUTOREFCOUNT ist nicht definiert!';
{$ENDIF}

Es kommt 'AUTOREFCOUNT ist nicht definiert!' an.

D.h. es ist nur für die System.dcu definiert.

Hab dann noch eine Textsuche über alle *.pas auf meiner SSD gemacht. Bis auf das Testprojekt wo ich es eben hinzugefügt hab kommt AUTOREFCOUNT nicht vor.

[hoika]

Hallo,
was ist mit einer normalen TObjectList?
FastMM4 zeigt dir ja auch die Create-Stelle des nicht freigegebenen Objektes an.
Ist das die richtige Stelle?

Fehlt in deiner eigenen Klasse vielleicht ein inherited ?

Zeig doch mal deinen einfachen Code.

[haentschman]

Moin...:wink:

Ich hatte noch nie mit den generischen Listen Probleme...nur wenn ich selbst Mist gebaut habe. :P Also vergesse erst mal den Autorefcount...:wink:

Frage:

Delphi-Quellcode:

DataList = class(TObjectList<TDataItem>)
.
.
myDataList.Free; // ist das auch die gleiche Instanz?

Gib mal die DataList Instanz frei...

[TBx]

Auch sehr beliebt ist es, beim Überschreiben des Destructors das override zu vergessen.
Dann ruft Free nämlich den Destructor des Vorfahren auf.

[Shark99]

Im Code wird DataList (und nicht myDataList) freigegeben, war ein Vertipper hier im Forum (d.h. das Problem ist nach wie vor da).

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, System.Generics.Collections, Generics.Defaults;

type
  TTestForm = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

  TDataItem = class
    Modified: int64;
    Data: string;
    constructor Create(iModified: int64 = 0; sData: string = '');
  end;

  TDataList = class(TObjectList<TDataItem>)
  private
   StringList: TStringList;
  public
    Constructor Create(AOwnsObjects: Boolean = True);
    Destructor Destroy;
  end;

var
  TestForm: TTestForm;
  DataList: TDataList;

implementation

{$R *.dfm}

constructor TDataItem.Create(iModified: int64 = 0; sData: string = '');
begin
  Inherited Create;
  Modified:= iModified;
  Data := sData;
end;

constructor TDataList.Create(AOwnsObjects: Boolean = True);
begin
  Inherited Create(AOwnsObjects);

  StringList := TStringList.Create;
end;

destructor TDataList.Destroy;
begin
  StringList.Free;
  Inherited Destroy;
end;

procedure TTestForm.Button1Click(Sender: TObject);
var DataItem: TDataItem;
begin
{$IFDEF AUTOREFCOUNT}
  Caption := 'AUTOREFCOUNT ist definiert!';
{$ELSE}
  Caption := 'AUTOREFCOUNT ist nicht definiert!';
{$ENDIF}

  DataList := TDataList.Create(True);
  DataItem := TDataItem.Create(0 ,'Abc');
  DataList.Add(DataItem);
  Button1.Caption := DataList[0].Data;
  DataList.Free;
end;
end.

Das spuckt FastMM aus:

Delphi-Quellcode:

--------------------------------2016/12/21 11:42:31--------------------------------
A memory block has been leaked. The size is: 100

This block was allocated by thread 0xEE8, and the stack trace (return addresses) at the time was:
4068EE [System.pas][System][@GetMem$qqri][4316]
4076CF [System.pas][System][TObject.NewInstance$qqrv][15447]
407EBE [System.pas][System][@ClassCreate$qqrpvzc][16757]
4B5A3E [System.Classes.pas][System.Classes][Classes.TStringList.$bctr$qqrv][6821]
5BC1D1 [System.Generics.Collections.pas][Unit1][Generics.Collections.%TObjectList__1$p15Unit1.TDataItem%.$bctr$qqro][2083]
5BAAD8 [Unit1.pas][Unit1][TDataList.$bctr$qqro][52]
5BAB63 [Unit1.pas][Unit1][TTestForm.Button1Click$qqrp14System.TObject][70]
523A31 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.Click$qqrv][7340]
53A887 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.Click$qqrv][5313]
53B401 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.CNCommand$qqrr26Winapi.Messages.TWMCommand][5774]
5234D8 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.WndProc$qqrr24Winapi.Messages.TMessage][7224]

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

The allocation number is: 704

Current memory dump of 256 bytes starting at pointer address 7FE7DEF0:
B4 25 49 00 00 00 00 00 00 00 00 00 A0 B8 E9 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31 2B 6B 7C
80 80 80 80 80 80 80 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
´  %  I  .  .  .  .  .  .  .  .  .  *  ¸  é    .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  1  +  k  |
€  €  €  €  €  €  €  €  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

--------------------------------2016/12/21 11:42:31--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

85 - 100 bytes: TStringList x 1

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

[Shark99]

Zitat:

Zitat von TBx (Beitrag 1356780)

Auch sehr beliebt ist es, beim Überschreiben des Destructors das override zu vergessen.
Dann ruft Free nämlich den Destructor des Vorfahren auf.

Das war es!! Danke!

Eine Frage hab ich noch. Beim Create() hatte ich auch keinen Override. Wieso wurde es trotzdem aufgerufen?

[Uwe Raabe]

Zitat:

Zitat von Shark99 (Beitrag 1356838)

Eine Frage hab ich noch. Beim Create() hatte ich auch keinen Override. Wieso wurde es trotzdem aufgerufen?

Weil du beim Create den Typ ja explizit davor schreibst.

[himitsu]

Weil die Instanz nicht im TObject.Create erstellt wird, sondern in TObject.NewInstance, welches der Compiler heimlich vor dem Create aufruft.
Fehlt bei Create das Inherited, dann sind Variablen der Vorfahren nicht initialisiert. z.B. bei TComponent-Nachfahren knallt es danach dann gern, wenn man es vergessen hat.

[freimatz]

Zitat:

Zitat von Shark99 (Beitrag 1356838)

Zitat:

Zitat von TBx (Beitrag 1356780)

Auch sehr beliebt ist es, beim Überschreiben des Destructors das override zu vergessen.
Dann ruft Free nämlich den Destructor des Vorfahren auf.

Das war es!! Danke!

Kommt da keine Warnung vom Compiler?

[Shark99]

Kommt keine Warnung.

[Der schöne Günther]

Doch.

Oh.

[Shark99]

Hast Recht. Warnungen diesen Typs waren Global abgeschaltet.

[Zacherl]

Zitat:

Zitat von Shark99 (Beitrag 1356878)

Hast Recht. Warnungen diesen Typs waren Global abgeschaltet.

Eigentlich immer eine schlechte Idee, Warnungen global zu deaktivieren.