Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[Uwe Raabe]

Zitat von DasWolf:

Zitat von Blup:

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
TObject(nil).Free; // läuft problemlos

Das ist falsch. Korrigiert mich bitte, wenn es nach Version Delphi 10.1 anders sein sollte.

Läuft auch unter 10.1 problemlos!

Delphi-Quellcode:

program Project769;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

begin
  try
    TObject(nil).Free;
    Writeln('Geht doch');
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[Dalai]

Ich meine mich zu erinnern, ein ähnliches oder gar gleiches Problem mit "Invalid handle" Exceptions gehabt zu haben gehabt zu haben, als ich ein Formular in einer DLL erzeugt hatte. Die Klasse TForm greift an bestimmten Stellen auf das TApplication-Objekt zu. In der DLL ist aber nie eine Instanz dieses Objekt erzeugt worden, und daher ist Application.Handle (und Application.MainFormHandle) nicht gesetzt und daher ungültig, wahrscheinlich 0. Daher musst du beim Erzeugen der Form in der DLL ein gültiges Handle an TForm.WndParent übergeben und damit indirekt Application.Handle befüllen.

Siehe auch https://www.delphipraxis.net/1293954-post10.html und der damit verbundene Thread. Das Handle ist bei mir das Hauptfenster des Programms, in dem Fall Total Commander, von dem ich dieses Handle auch bekomme.

Grüße
Dalai

[himitsu]

Dann kommt der Fehler aber nicht wegen dem NIL.
Bei NIL wird nichts gemacht, so wie es sein soll.

Sollte es nicht nil sein und in dem Objekt, was eventuell auch ein ungültiger Zeiger sein könnte, stimmen irgendwelche Zeiger/Handle nicht, dann ist das kein Problem von Free oder FreeAndNil.

Zitat:

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;

procedure TObject.DisposeOf;
type
  TDestructorProc = procedure (Instance: Pointer; OuterMost: ShortInt);
begin
{$IFDEF AUTOREFCOUNT}
  if Self <> nil then
  begin
    Self.__ObjAddRef; // Ensure the instance remains alive throughout the disposal process
    try
      if __SetDisposed(Self) then
      begin
        _BeforeDestruction(Self, 1);
        TDestructorProc(PPointer(PByte(PPointer(Self)^) + vmtDestroy)^)(Self, 0);
      end;
    finally
      Self.__ObjRelease; // This will deallocate the instance if the above process cleared all other references.
    end;
  end;
{$ELSE}
  Free;
{$ENDIF}
end;

[TheSledgeHammer]

Zitat von Dalai:

Ich meine mich zu erinnern, ein ähnliches oder gar gleiches Problem mit "Invalid handle" Exceptions gehabt zu haben gehabt zu haben, als ich ein Formular in einer DLL erzeugt hatte. Die Klasse TForm greift an bestimmten Stellen auf das TApplication-Objekt zu. In der DLL ist aber nie eine Instanz dieses Objekt erzeugt worden, und daher ist Application.Handle (und Application.MainFormHandle) nicht gesetzt und daher ungültig, wahrscheinlich 0. Daher musst du beim Erzeugen der Form in der DLL ein gültiges Handle an TForm.WndParent übergeben und damit indirekt Application.Handle befüllen.

Siehe auch https://www.delphipraxis.net/1293954-post10.html und der damit verbundene Thread. Das Handle ist bei mir das Hauptfenster des Programms, in dem Fall Total Commander, von dem ich dieses Handle auch bekomme.

Grüße
Dalai

Also ich hab das jetzt auch ausprobiert und es ist derselbe Fehler, wie wenn ich das via Application.Handle setze. Wenn ich weder das eine noch das andere mache, erhalte ich zumindest keinen invalid handle value Fehler mehr Also das wird es dann auch nicht sein, so wie himitsu das auch schon vermutet hat.

Und was ich auch ausschließen kann, war meine Vermutung, dass der parallele Zugriff auf eine einzige physische Datei durch mehrere Instanzen des TIniFile-Objekts zu Problemen führen würde. Hab mir da eine Test-Applikation geschrieben mit 4 Timern drauf und die haben in die eine Ini-Datei problemlos geschrieben. Zwei Zeitstempel waren sogar auf die Milisekunde identisch, also irgendwie ist das schon synchronisiert; zumindest bei EXE-Projekten. Ob das bei DLL-Projekten auch so ist, das wissen nur die Götter des Olymps

[DasWolf]

Zitat von Uwe Raabe:

Zitat von DasWolf:

Zitat von Blup:

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
TObject(nil).Free; // läuft problemlos

Das ist falsch. Korrigiert mich bitte, wenn es nach Version Delphi 10.1 anders sein sollte.

Läuft auch unter 10.1 problemlos!

Delphi-Quellcode:

program Project769;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

begin
  try
    TObject(nil).Free;
    Writeln('Geht doch');
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

"dann passiert nichts" ist definitiv falsch. Wer macht denn bitteschön TObject(nil).Free; ?

Delphi-Quellcode:

var
  fObject: TMyObj;
begin
  fObject := TMyObj.Create;
  try
    fObject.Trallalla;
  finally
    fObject.Free;
  end;

  fObject.Free;  //was passiert hier?
end;

Ein Unterschied wäre das hier:

Delphi-Quellcode:

var
  fObject: TMyObj;
begin
  fObject := TMyObj.Create;
  try
    fObject.Trallalla;
  finally
    fObject.Free;
    fObject := nil;  //Ein kleiner, aber feiner Unterschied
  end;

  fObject.Free;  //dann passiert nichts. 
end;

[DeddyH]

Das ist aber auch völlig unterschiedlicher Code. Eine Instanzvariable, die nil ist, verursacht beim Aufruf von Free keinen Fehler (im Gegensatz zu Destroy). Darum ging es in der Aussage.

[Blup]

Zitat von dummzeuch:

Zitat von Blup:

Parameter als PChar sind problemlos verwendbar, solange die übergebenen Zeichenketten in der DLL nicht verändert werden.
Wieder auf String casten und dann verändern ist nicht zulässig.

Doch. Ein "auf String casten" erzeugt eine Kopie des Inhalts.

Man muss nur darauf achten, dass auf beiden Seiten das gleiche PChar verwendet wird, oder besser gleich auf beiden Seiten PAnsiChar oder PWideChar, dann ist es eindeutig.

Das ist richtig, die Kopie kann man natürlich verändern. Delphi behandelt PChar, PAnsiChar, PWideChar anders wie normale Pointer.

[jaenicke]

Zitat von DasWolf:

Ein Unterschied wäre das hier:

Es ging ja um die Prüfung auf Assigned, also genau auf die Prüfung auf nil. Die passiert eben schon im Free und ist daher unnötig.

Wenn die Referenz nicht nil ist, knallt es mit oder ohne Assigned ggf., ist sie nil, knallt es in beiden Fällen nicht.

[Codehunter]

Zitat von DasWolf:

Zitat von Blup:

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
TObject(nil).Free; // läuft problemlos

Das ist falsch. Korrigiert mich bitte, wenn es nach Version Delphi 10.1 anders sein sollte.

In meinem 10.2.3 knallt das mit einer AV. In Verbindung mit dem eigenwilligen Create innerhalb des try-except-Block könnte es durchaus sein dass die Variable weder nil noch ein gültiges TIniFile ist.

Ich verwende jedenfalls nie Object.Free sondern immer FreeAndNil(Object). Mir sind solche AVs beim Free auch gut bekannt, die treten gerne mal auf wenn es an anderer Stelle vor dem Free einen Speicherüberlauf gegeben hat.

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

[himitsu]

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.

Das Einzige, wo FreeAndNil anders arbeiten könnte, als wie Free, das wäre im Nextgen, wo dabei auch noch die Referenzzählung mitspielen würde,
wobei dort Free ja eigentlich garnichts macht. (dessen Inhalt ist dort deaktiviert)