[FM] Free auf nil wird zu self.free

[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 von Darlo:

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 von Darlo:

..., 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 von Bernhard Geyer:

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

[Bernhard Geyer]

Zitat von Darlo:

Zitat von Bernhard Geyer:

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 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 sl.Free in diesem Fall eben zur Freigabe von Button2.

[Iwo Asnet]

Zitat von Darlo:

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

[himitsu]

Delphi optimiert diese Objekt-variable weg.
Diese wird ja nur an einer Stelle verwendet, weswegen sie direkt in den Registern liegen kann.
z.B. in EAX
Jetzt kommt es darauf an, wofür vorher dieses EAX verwendet wurde
und schon hat man das in dieser Variable, was gerade in diesem EAX drinsteht.