[FM] Free auf nil wird zu self.free

[Darlo]

Hallo zusammen,

mir ist gerade etwas merkwürdiges unter FM aufgefallen.

Folgender Beispielcode

Code:

procedure TForm1.btnTestClick(Sender: TObject);
var
  sl: TStringList;
begin
  sl.Free;
end;

Führt unter Firemonkey dazu, dass der Button freigegeben wird, unter VCL kommt es
wie zu erwarten zu einer Exception.

Kann mir jemand das Verhalten unter FM erklären, oder ist es ein Bug?

Gruß

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1153834)

Führt unter Firemonkey dazu, dass der Button freigegeben wird, unter VCL kommt es
wie zu erwarten zu einer Exception.

Kann mir jemand das Verhalten unter FM erklären, oder ist es ein Bug?

Gruß

Du kannst eigentlich nur erwarten das *irgendwas* passiert. Je nachdem auf was sl zeigt. Wenn es zufälligerweise die Button-Instanz ist wird diese Freigegeben. Wenn du glück hast bekommst du eine sinnvoller Exception-Meldung

[himitsu]

Das wird Zufall sein.

Lokale Variablen werden nicht automatisch initialisiert.
Es steht dort also ein "Zufallswert" drin.

Und bei VM wird in der Speicheradresse, welche DU hast vergessen zu initialisieren, vielleicht "zufällig" die Button-Komponente drinstehn.

Fazit: DU bist Schuld.


[edit]
:stupid:

[Bummi]

Eine nicht initialisierte Stackvariable freizugeben ist der Bug.
Ob FM hier nur zufällig den Button abgelegt hat, oder ob es da ein System gibt kann ich nicht beurteilen.

[Darlo]

Dass der Code fehlerhaft ist, ist mir durchaus klar. Sollte ja
auch nur ein vereinfachtes Beispiel dazu sein...

Mir scheint es, dass nicht initialisierte lokale Variablen unter FM
stets auf den Sender der Procedure zeigen, da

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
  sl: TStringList;
begin
  sl.Free;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  button1.OnClick(sender);
end;

button2 verschwinden läßt.

Danke soweit für eure Antworten, ich dachte dass nicht initialisierte Variablen
nirgendwo hinzeigen.

Gruß

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1153843)

Mir scheint es, dass nicht initialisierte lokale Variablen unter FM
stets auf den Sender der Procedure zeigen,

Der Compiler der die Anwendung erzeugt ist der gleiche. Was sollte da anders sein?

Zitat:

Zitat von Darlo (Beitrag 1153843)

..., ich dachte dass nicht initialisierte Variablen nirgendwo hinzeigen.

Hätte Delphi eine Managed Framework/Garbage Collector dann wäre das so. Aber wenn man die Compilerwarnungen die bei sowas auftauchen auch nicht ignoriert dann behebt man die Programmierfehler auch.

[Darlo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1153850)

Der Compiler der die Anwendung erzeugt ist der gleiche. Was sollte da anders sein?

Unter VCL kommt eine Exception

Nur um das zu betonen, ich wollte das Verhalten verstehen, dass hier ein Programmierfehler vorliegt ist klar.:duck:
Gruß

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1153852)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1153850)

Der Compiler der die Anwendung erzeugt ist der gleiche. Was sollte da anders sein?

Unter VCL kommt eine Exception

Das was anders kommst hast du ja geschrieben. Aber bei VCL und FM wird ja der gleiche Compiler genommen. Und auf dieser unteren ebene weiß der Compiler ja nichts mehr davon jetzt VCL oder FM vor sich zu haben. Also kann es eigentlich nur zufall sein was passiert.

[Uwe Raabe]

Ein Pointer ist auch nichts anderes als ein 4 oder 8 Byte großer Speicherbereich, dessen Inhalt als Speicheradresse (in diesem Fall einer TStringList-Instanz) interpretiert wird. Da bis zum Aufruf von sl.Free noch kein korrekter Inhalt in diesen Speicherbereich verbracht wurde (z.B. durch ein

Delphi-Quellcode:

sl := TStringList.Create

), befinden sich darin eben noch die Bits, die irgendwie vorher von einem anderen Prozeduraufruf drin gestanden haben (z.B. dein Geburtsdatum oder die Größe deiner Festplatte oder die Speicheradresse von Button2).

Wenn man jetzt diesen zufälligen Speicherinhalt als Speicheradresse einer TStringList interpretiert, dann liegt diese Adresse mit hoher Wahrscheinlichkeit nicht im erlaubten Adressraum des aktuellen Prozesses und führt zu einer Schutzverletzung.

Wenn es sich aber zufällig um die Adresse von Button2 handelt, dann ist das sehr wohl eine gültige Adresse. Da Free für alle Objekt-Instanzen das selbe tut, führt der Aufruf von

Delphi-Quellcode:

sl.Free

in diesem Fall eben zur Freigabe von Button2.

[Iwo Asnet]

Zitat:

Zitat von Darlo (Beitrag 1153843)

Mir scheint es, dass nicht initialisierte lokale Variablen unter FM
stets auf den Sender der Procedure zeigen, da... button2 verschwinden läßt.

Das ist wirklich merkwürdig, denn die lokale Variable liegt auf dem Stack ÜBER dem Wert von 'Sender'. Bin mir nicht sicher, aber da ist glaub ich auch noch eine Rücksprungadresse dazwischen.

'sl' zeigt also wirklich auf das, was vorher einmal auf dem Stack stand. vielleicht ist das ja der Button, nur liegt das dann nicht am Sender, sondern vermutlich an der Click-Verarbeitung der Button-Komponente.

Wenn sich hier nun die VCL und FM unterscheiden (wovon auszugehen ist), wäre das eine Erklärung