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:

DataList = class(TObjectList<TDataItem>)

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

FCryptoLib := TCryptographicLibrary.Create(nil);

Im Destroy() gebe ich den Speicher wieder frei:

FCryptoLib.Free;

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

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

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 {$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 von nahpets:

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

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

Frage:

Delphi-Quellcode:

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

Gib mal die DataList Instanz frei...