Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1481792)

Ob Free oder FreeAndNil macht keinen Unterschied, denn FreeAndNil ruft auch nur Free auf.
Außer dass FreeAndNil eigentlich NilAndFree heißen müsste, da es zuerst die Variable auf NIL setzt und danach Free aufruft.

Womöglich ist genau das der Punkt? Wobei, wenn ich mir die Quelle von FreeAndNil anschaue, dann tut das schon noch ein bissle mehr als das. Jedenfalls war es für mich immer von Vorteil, die Variable definiert auf nil zu setzen. Und ich bin mir nicht so ganz sicher, ob hier nicht noch ein wenig Compiler Magic ins Spiel kommt...

[himitsu]

FreeAndNil kopiert nur den Objektzeiger
und setzt vor dem Free die originale Variable auf NIL. (erspart sich so ein TryFinally)

Delphi-Quellcode:

Temp := VAR;  // mit ARC sind einfach die Zeilen 1 und 3 nutzlos und werden weggelassen
VAR := nil;
Temp.Free;

// statt

try
  VAR.Free;
finally
  VAR := nil;
end;

Ohne ARC, passiert mit der Objekt-Referenz nichts. (das kopieren der Variable macht nichts, außer den Pointer/Integer zu kopieren)

Und mit ARC wird effektiv nur die VARiable auf NIL gesetzt. (original würde die Variable kopiert, dabei AddRef/INC ausgeführt,
dann die alte Variable auf NIL gesetzt und somit ReleaseRef/DEC, und am Schluß Free, was aber im bei ARC garnichts macht)


PS: Das Application.FormCreate ist gegenüber dem TForm.Create das Selbe, wie FreeAndNil gegenüber einem Free.
Dort wird die Variable zuerst gesetzt, bevor Create ausgeführt wird. (eigentlich wird die Variable ja erst gesetzt, nachdem das Create fertig ist, was blöd ist, wenn eine Form-Referenz in der DFM vorkommt, oder jemand im Create oder einem Property-Setter so blöd ist und die globale Form-Variable benutzt, anstatt Self)
Und beim FreeAndNil wird eben die Variable gelöscht, bevor Destroy ausgeführt wird.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1481791)

In meinem 10.2.3 knallt das mit einer AV.

Das wäre dann aber ein ziemlich böser Bug. Bei mir läuft es mit 10.2.3 einfach durch wie es auch sein sollte.
Wie sieht denn der Stacktrace aus bzw. was passiert, wenn du in das Free hinein debuggst? Eigentlich sollte dort Self = nil sein und somit kein Code ausgeführt werden:
Anhang 53590

Bist du sicher, dass nicht FastMM oder ähnliches aktiv ist? Denn die prüfen so etwas und lösen dann eine Exception aus.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1481822)

Bist du sicher, dass nicht FastMM oder ähnliches aktiv ist? Denn die prüfen so etwas und lösen dann eine Exception aus.

Dir Prüfung auf nil erfolgt doch im Free. Ich glaube kaum, dass FastMM das in irgendeiner Weise abfängt, geschweige denn sich überhaupt dafür interessiert.

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1481824)

Dir Prüfung auf nil erfolgt doch im Free. Ich glaube kaum, dass FastMM das in irgendeiner Weise abfängt, geschweige denn sich überhaupt dafür interessiert.

Das würde ich auch nicht vermuten, aber so etwas wäre die einzige Variante (außer kaputtem Speicher), die ich mir vorstellen kann. Vielleicht gibt es ja ein Tool, das sich da einklinkt (warum auch immer).

Bei FastMM passiert (eben getestet) in der Tat nichts.

[Uwe Raabe]

Ich tippe schlichtweg auf Test-Case-Error. Ich kann mir nicht vorstellen, dass mein Beispiel in irgendeiner Delphi-Version (eventuell nach Anpassung der uses-Anweisung) eine Exception auslöst.

[stahli]

Sind da vielleicht noch Threads am Arbeiten, die irgendein Problem haben (und es nur so aussieht, als läge es am TIniFile)?

[TheSledgeHammer]

Zitat:

Zitat von Codehunter (Beitrag 1481791)

Noch ein Gedanke: Ist PChar hier überhaupt gleich PChar aus der Hostanwendung? Stichwort PAnsiChar und PWideChar...

Also PChar in der Anwendung ist idetnisch zu PChar in der DLL, ja :) Es ist mit ein und derselben Delphi-Version kompiliert und beide Male als Win32.

[TheSledgeHammer]

Zitat:

Zitat von stahli (Beitrag 1481854)

Sind da vielleicht noch Threads am Arbeiten, die irgendein Problem haben (und es nur so aussieht, als läge es am TIniFile)?

Auch wenn ich Threads an sich ganz gern habe, ist das in dem Fall auszuschließen. Ich hatte ja bereits meinen Code gepostet und da war nix von irgendwelchen Threads und die lokale Variable ist auch echt nur lokal.

[TheSledgeHammer]

Zitat:

Zitat von Codehunter (Beitrag 1481795)

Zitat:

Zitat von himitsu (Beitrag 1481792)

Ob Free oder FreeAndNil macht keinen Unterschied, denn FreeAndNil ruft auch nur Free auf.
Außer dass FreeAndNil eigentlich NilAndFree heißen müsste, da es zuerst die Variable auf NIL setzt und danach Free aufruft.

Womöglich ist genau das der Punkt? Wobei, wenn ich mir die Quelle von FreeAndNil anschaue, dann tut das schon noch ein bissle mehr als das. Jedenfalls war es für mich immer von Vorteil, die Variable definiert auf nil zu setzen. Und ich bin mir nicht so ganz sicher, ob hier nicht noch ein wenig Compiler Magic ins Spiel kommt...

D.h. irgendwie sollte ich es mit FreeAndNil probieren, aber irgendwie auch nicht? :wall: