Objekte / Freigaben / Free / Nil

[Namenloser]

Zitat von Alex_ITA01:

Das ist ja nur eine Minianwendung wo es recht übersichtlich ist. Wie kann man denn ganz sicher die Objekte freigeben und falls jemand anderes (vielleicht ein parallel laufender Thread) diese auf Gültigkeit abfragt auch wirklich feststellen, dass man noch drauf zu greifen kann?!

Geht nicht. Musst du anders lösen, z.B. über ein Observer-Pattern.

Und Multi-Thread ist noch mal eine Sache für sich...

[Alex_ITA01]

@jaenicke: Das war ja auch der Vorschlag von Uwe Raabe aber das Endergebnis ist ja das gleiche. Ich kann nicht erkennen, ob das Objekt noch da ist oder nicht.

Sowohl in meinem Beispiel in Post 1 als auch die Variante mit OwnsObjects wird mir mit ReportOnMemoryLeaks auch kein Speicherleck abgezeigt.
Ist ja schön wenn das auch so ist aber ich verstehe nur nicht, warum ich auf alle Eigenschaften und Variablen des Objekts zugreifen kann obwohl es eigentlich freigegeben wurde.
Gibt es keine Variante, dass Objekt so freizugeben, dass eine if Assigned Abfrage dann auch wirklich "False" liefert?

Gruß

[Uwe Raabe]

Zitat von Alex_ITA01:

Gibt es keine Variante, dass Objekt so freizugeben, dass eine if Assigned Abfrage dann auch wirklich "False" liefert?

Solange du die besagte Variable nicht selbst auf nil setzt, nein. Dein Problem ist, daß mehrere Variablen auf dasselbe Objekt verweisen. Wird dieses Objekt freigegeben, zeigen alle diese Variablen auf einen ungültigen Speicherbereich. Das kannst du ohne erheblichen Aufwand nicht vermeiden. Schon gar nicht im Multithread-Bereich.

[stahli]

Das Problem ist nicht so einfach zu lösen.

Hier mal ein paar ältere Diskussionen dazu:
http://www.delphipraxis.net/166899-i...eferenzen.html
http://www.delphipraxis.net/159095-r...e-objekte.html

[Alex_ITA01]

Ok danke für die Info. Wo wäre denn die richtige Stelle zum Nil setzen, wenn ich es selber machen muss @Uwe?

Gruß

[Uwe Raabe]

Zitat von Alex_ITA01:

Ok danke für die Info. Wo wäre denn die richtige Stelle zum Nil setzen, wenn ich es selber machen muss @Uwe?

Nach deinem gezeigten Code zu urteilen, wäre folgende Code-Sequenz im FormDestroy korrekt:

Delphi-Quellcode:

procedure TForm4.FormDestroy(Sender: TObject);
begin
  tmpObject := nil;
  MyObjList.Free;
  MyObjList := nil;
end;

Die beiden if-Anweisungen würden demnach immer fehlschlagen und der dahinter liegende Code kann somit eliminiert werden. Solange die beiden Variablen nicht noch anderswo verwendet werden, braucht man sie dann aber auch nicht auf nil setzen. Damit reduziert sich das FormDestroy auf ein simples MyObjList.Free;

Ich vermute aber, daß dein eigentlicher Code etwas ganz anderes macht. Dazu kann ich so natürlich nichts sagen.

[Thom]

Zitat von stahli:

Das Problem ist nicht so einfach zu lösen.

Hier mal ein paar ältere Diskussionen dazu:
http://www.delphipraxis.net/166899-i...eferenzen.html

Wie die Zeit vergeht...
Auf den diesjährigen Delphi-Tagen hatte ich dazu übrigens die Funktionsweise live im Debugger demonstriert.
Es funktioniert also - wenn auch (momentan) nur unter Windows, da dazu intern Assemblerfunktionen verwendet werden.

[jaenicke]

In den meisten Anwendungsfällen sind in so einem Fall aber eher Interfaces passend. Dann braucht man sich nicht darum zu kümmern und das Objekt wird freigegeben, wenn es von keiner Seite mehr benutzt wird. Umgekehrt hat man es aber auch überall noch, auch wenn es in der ursprünglichen Liste schon weg ist.

[Alex_ITA01]

Danke für die zahlreichen Hinweise.
Ich habe nur noch zwei letzte Fragen

Aktuell habe ich die Variante mit den OwnsObjects aktiv und im FormDestroy rufe ich zur Zeit nur "FreeAndNil(MyObjList);" auf. Ich habe jetzt ja gelernt, dass dann das globale Objekt "tmpObject" noch vorhanden ist aber auf ein ungültigen Speicherbereich zeigt.

1) Woher weiß der Speichermanager eigentlich, dass diese Speicheradresse "ungültig" ist? Gibt es da irgendein Flag dafür?
2) Das das "if Assigned(tmpObject) then" weiterhin nach "FreeAndNil(MyObjList);" im FormDestroy funktioniert, habe ich verstanden aber warum crasht das Programm nicht, wenn ich dann auch auf die Inhalte und Funktionen von "tmpObject" zugreife nach der "if Assigned(tmpObject) then"-Abfrage?

Gruß

[stahli]

Wenn Du ein Objekt freigibst wird nur der Speicherbereich als verfügbar definiert.

Wenn Du jetzt noch darauf zugreifst und der Speicher noch nicht überschreiben wurde, dann kann das noch gut gehen.
Es kann aber auch sein, dass es in unvorhergesehener Form knallt, wenn die dort stehenden Binärdaten schon (teilweise) überschreiben wurde.


In meinem aktuellen Framework habe ich übrigens folgende Lösung:

In der Datanschicht sammle ich alle erzeugten Objekte in einer sortiereten Liste.
Diese fordere ich dann zur Laufzeit anhand einer Id an. Durch Binary Search geht das wirklich schnell.
Wurde ein Objekt bereits aufgelöst, gibt die Anfrage nil zurück.
Man muss dann halt immer wieder die Objekte "abfordern".

Die Objekte müssen dafür dann auch speziell angepasst sein.
So funktioniert das gut, aber halt nur in einem festgelegten Rahmen.

Delphi-Quellcode:

function TssIO_Custom.GetObject(Id: TssId): TssObject;
var
  Index: Integer;
  ssObj: TssObject;
begin
  Result := nil;
  ssObj := TssObject.Create(nil, Id, True);
  if ssObjectList.BinarySearch(ssObj, Index) then
    Result := ssObjectList[Index];
  FreeAndNil(ssObj);
end;

procedure TssIO_Custom.RegisterObject(ssObj: TssObject);
var
  Index: Integer;
begin
  if not Assigned(ssObj) then
    Exit;
  if ssObj.HideMode then
    Exit;
  if not ssObjectList.BinarySearch(ssObj, Index) then
    ssObjectList.Insert(Index, ssObj);
end;

procedure TssIO_Custom.UnregisterObject(ssObj: TssObject);
begin
  if not Assigned(ssObj) then
    Exit;
  if ssObj.HideMode then
    Exit;
  ssObjectList.Extract(ssObj);
end;

Eine Compilerlösung, Referenzen auf aufgelöste Objekte automatisch zu nilen ist wohl nicht in Aussicht.