Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[TheSledgeHammer]

Liebes Forum,

die letzte Zeit ereilten mich diverse madExcept-Mails bzgl. eines offenkundigen Problems mit einer Ini-File-Instanz des Objekts System.TIniFile. Das Interessante daran: laut madExcept Callstack soll das Problem beim Zerstören der Instanz auftreten. Es hagelt dann so eine wunderbar aussagekräfte Fehlermeldung a la
"Access violation at address [...] Read of address [...]".

Jetzt habe ich mir mal gedacht, dass ich mir das genauer anschauen muss. Zunächst mal den Code, den ich verwende (stark gekürzt):

Delphi-Quellcode:

iniFile := nil;
try
  iniFile := TIniFile.Create(FIniFile);
  // ReadBool, ReadString, etc.
finally
  if iniFile <> nil then
    iniFile.Free;
end;

Gesetzt dem Fall, dass ich nicht wieder was verpasst habe und der Aufruf von Free tut auch noch immer das, was er soll (den Destructor aufrufen), dann sind an dieser Stelle an sich keine Fehler zu erwarten.

Dennoch sind ja offenbar Zugriffsfehler da, sonst würde madExcept sich ja nicht melden. :gruebel:

Ich hab mir also mal die Klasse System.TIniFile genauer zu Gemüte geführt. Diese leitet ja von TCustomIniFile ab und die dann wiederum von TObject. Die Klasse TIniFile besitzt einen eigenen Destruktor, aber keinen eignen Konstruktor. Die (Eltern-)Klasse TCustomIniFile ist dann das passende Pendant dazu mit einem eigenen Konstruktor aber keinem Destruktor. Mal abgesehen davon, dass alleine das schon verwirrend ist und meiner Meinung nach nicht sauber, wird es noch interessanter, wenn man sich Konstruktor und Destruktor genauer ansieht:

Delphi-Quellcode:

constructor TCustomIniFile.Create(const FileName: string);
begin
  FFileName := FileName;
end;

destructor TIniFile.Destroy;
begin
  UpdateFile;         // flush changes to disk
  inherited Destroy;
end;

Meine Frage an der Stelle: wie kann es sein, dass eine Klasse von TObject erbt, aber dessen Konstruktor nicht aufruft? Ich erwarte eigentlich ein inherited Create. Zudem frage ich mich dann noch, wie es sein kann, dass im Destruktor dann ein inherited Destroy aufgerufen wird, was meiner Meinung nach den Destruktor desjenigen TObjects ausführt, das ja offenbar niemals erzeugt wurde. :gruebel:

Und um das jetzt noch weiter abzurunden: Fehler bekomme ich nur, wenn ich das in einer DLL ausführe! In unseren Executables, die wir seit Jahrzehnten haben und pflegen, ist mir so etwas noch nicht unter gekommen.

Kann mir bitte jemand erklären, wieso diese Objekte überhaupt funktionieren? Die Klasse TCustomIniFile wird erzeugt, aber ohne explizit den Konstruktor von TObject aufzurufen. Gleichzeitig wird dann aber explizit der Destruktor von TObject aufgerufen, wenn es daran geht, TIniFile zu zerstören. Die folgende Frage mag jetzt doof klingen aber ich muss sie stellen: Sind Konstruktoren implizit und Destruktoren nicht? Wieso klappt das bei EXE-Projekten in Delphi, aber offenbar bei DLL-Projekten nicht? Mache ich denn in der Verwendung was falsch, bspw. auch bei der Konfiguration des DLL-Projekts?

Ich bin für jede Unterstützung dankbar.

[Sinspin]

Hallo,

So hat es bei mir noch nie Probleme gegeben:

Delphi-Quellcode:

iniFile := TIniFile.Create(FIniFile);
try
  // ReadBool, ReadString, etc.
finally
  iniFile.Free;
end;

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481565)

Meine Frage an der Stelle: wie kann es sein, dass eine Klasse von TObject erbt, aber dessen Konstruktor nicht aufruft? Ich erwarte eigentlich ein inherited Create. Zudem frage ich mich dann noch, wie es sein kann, dass im Destruktor dann ein inherited Destroy aufgerufen wird, was meiner Meinung nach den Destruktor desjenigen TObjects ausführt, das ja offenbar niemals erzeugt wurde. :gruebel:

Das passt so. Der Constructor von TObject ist eh leer. Bzw. Compilermagic.
Der Constructor dient dazu lokale Variablen zu initialisieren. TObject hat da wohl nichts.
Natürlich ist es unsauber den Aufruf nicht zu schreiben, oder zumindest ein

Delphi-Quellcode:

inherited;

Besonders wenn man langfristig denkt und sich das Verhalten für TObject auch mal ändern könnte.

[dummzeuch]

Delphi-Quellcode:

iniFile := nil;
try
  iniFile := TIniFile.Create(FIniFile);
  // ReadBool, ReadString, etc.
finally
  if iniFile <> nil then
    iniFile.Free;
end;

Eigentlich macht man das (wie bei anderen Objekten) so:

Delphi-Quellcode:

iniFile := TIniFile.Create(FIniFile);
try
  // ReadBool, ReadString, etc.
finally
  iniFile.Free;
end;

oder ggf. im finally auch FreeAndNil statt .Free, aber darüber lässt sich streiten.

Die if-Abfrage auf <> nil ist unnötig, da .Free das bereits selbst macht. Und wenn man die Zuweisung von iniFile vor das try setzt, kann man in Finally sowieso davon ausgehen, dass es assigned ist, denn eine evtl. Exception im Construtor würde ja das try..finally komplett überspringen.

[jaenicke]

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481565)

Und um das jetzt noch weiter abzurunden: Fehler bekomme ich nur, wenn ich das in einer DLL ausführe! In unseren Executables, die wir seit Jahrzehnten haben und pflegen, ist mir so etwas noch nicht unter gekommen.

Der komplette Stacktrace könnte hilfreich sein und auch die Adressen (sind sie nahe 0 oder "normal"?).

Ist das eine einfache DLL Funktion, in der das passiert? Kannst du den Rest dort vielleicht einfach auskommentieren zum Testen?

Wichtig bei Zugriffsverletzungen:
Diese können z.B. auch auftreten, wenn der Speicher irgendwo überschrieben wurde und deshalb das Objekt (bzw. ein Zeiger darin) kaputt ist. Die Ursache kann also auch am anderen Ende des Projekts liegen.

[DeddyH]

Wird die Instanz vielleicht aus der DLL noch an ein Executable weitergereicht, oder wird sie rein intern verwendet? Lokale Variable oder globale Variable/Feld?

[himitsu]

Die Delphi-Klassen werden vor Create erzeugt.
Stell dir einfach vor das Erstellen passiert im ersten BEGIN jedes CREATE, wenn die Klasse zu dem Zeitpunkt noch nicht initialisiert wurde, dann wird NewInstance ausgeführt.

Das Selbe ist übrigens auch beim Destructor, wo quasi im END die Klasse gelöscht wird.
Im Constructor/Destructor werden dann nur noch Dinge innerhalb der Klasse geregelt, wie z.B. erstellen/freigeben von Variablen der Klasse, aber nicht die Klasse selbst.

Und ja, es sollte zwar nicht, aber es "kann" auch die Ausfühung der Constructor/Destructor des Vorfahren übersprungen werden, indem kein Inherited aufgerufen wird.
(z.B. wenn die Nachfolgeklasse etwas ganz anders machen will und diesen Teil des Vorfahren "entfernt" und es dann eventuell selber/anders löst)
Normalerweise ist in TObjekt dort auch kein Code drin, warum es "meistens" nicht stört,
aber ja, per se sollte man immer ein Inherited machen, auch wenn "aktuell" im Vorfahren nichts drin ist .... wer weiß ob es sich mal ändern wird.




Ach ja, .Free hat bereits ein If-Assigned eingebaut.
Dein

Delphi-Quellcode:

if iniFile <> nil then

ist somit nutzlos (auch wenn es nicht stört, wenn doppelt geprüft wird)
PS: Das ist auch einer der Gründe, warum man Free aufrufen soll, und nicht direkt Destroy.

PS: Free tut im ARC garnichts. (dort wird/wurde nur über den Referenzzähler freigegeben, ähnlich wie bei den Interfaces ... als funktionierender Ersatz wurde dafür dann das DisposeOf erfunden, anstatt das "abweichende" Verhalten in eine "neue" Funktion zu verlagen :wall:)




Das normale TIniFile/TCustomIniFile macht im Constructor/Destructor eigentlich garnichts,
denn alle Arbeit nur innerhalb jeder einzelnen Read/Write-Methode erledigt wird.
Das UpdateFile im Destructor macht daher bei der normalen Windows-TIniFile ebenfalls nichts. (der Aufruf ist dort nur für die Ableitungen ala TMemIniFile drin enthalten)

Wenn etwas sich automatisch freigibt, dann brauch ich es nur erstellen (das muß nicht im Constructor gemacht werden, sondern kann auch erst beim ersten Zugriff passieren) und nicht wieder freigeben.
-> ein eigener Destrucor ist dann nicht nötig
Und wenn man etwas erst später erstellt, dann ist dafür auch kein eigener Constructor nötig.

[TomyN]

Hi,

ich vermute auch ein Problem an anderer Stelle. Wird denn noch neben dem Lesen was anderes gemacht? Wie sieht die Datenübergabe zur / von der DLL aus?

[hoika]

Hallo,
die Signatur der Methode wäre interessant.
Und ich würde mal den kompletten Code auskommentieren,
dann tritt der Fehler wahrscheinlich nicht auf.

[Blup]

Welcher Funktionen (Parameter und Rückgabewerte) hat deine DLL?
Wenn man nicht sicher stellt, dass DLL und Anwendung die selbe Instance des Speichermanagers verwenden, gibt es schnell Probleme (insbesondere Strings, Array).
Ähnliches gilt für das Application-Object (Formulare, Steuerelemente).
Die Zugriffsverletzung ist dann nur noch ein Symptom, das an jeder Stelle auftreten kann, obwohl die Ursache ganz wo anders liegt.

[TheSledgeHammer]

Hallo alle zusammen,

vielen, vielen Dank für die Fülle an Infos und Erläuterungen. Ich versuche mal in einem einzigen Post noch zusätzlich Infos zu meinem Fall zu geben. Ich hoffe, ich vergesse nichts ;)

Es wurde nach dem Stacktrace gefragt, den ich gerne hier an den Post ran hänge. Und zwar tue ich das in Form des Bugreports, den ich von madExcept bekommen habe. Ich hab mal diejenigen Infos entfernt, die meiner Meinung nach nicht relevant bzw. benutzerbezogen sind und daher nicht unbedingt ins WWW müssen ;) Zur Erläuertung: die Applikation, die die DLL einbindet, trägt den namen "edmWarml.exe". Die DLL selbst hat den Namen "DynSearchDialog.dll". In dieser DLL wird ein Formular (TForm) erzeugt (Name "DynamicSearchDialog") und hierin gibt es wiederum die Prozedur "LoadIni". Und genau dort erstelle ich dann das TIniFile Objekt, arbeite damit und gebe es wieder frei; exakt so, wie ich es im ersten Post beschrieben habe.

Auch wurde an anderer Stelle gefragt, ob es globale Variablen etc. gibt, ich denke, das sollte ich hier auch gleich erwähnen: nein! Das TForm-Objekt existiert übrigens nur innerhalb der DLL und da wird nichts nach außen gegeben. Sämtliche Zugriffe auf "public" Methoden des TForm-Objekts erfolgen durch entsprechend exportierte Methoden der DLL. Und auch sonst arbeite ich nicht mit globalen Variablen ;) wo es sich vermeiden lässt (ist ja nicht überall möglich, leider). Das TIniFile-Objekt existiert auch nur im Kontext der Prozedur LoadIni. Also dass da an anderer Stelle des Projekts/Codes Speicher verbogen wird, halte ich doch für sehr unwahrscheinlich. Das Objekt hat nur ein sehr, sehr kurzes Leben :D

Und meine DLL exportiert keinerlei managed types: weder String, noch Array, noch irgendwelche Objekte. Alles ist als CDECL deklariert und wie gesagt: das IniFile-Objekt ist auch nichts, was in einer direkten DLL-Methode steht.

[freimatz]

Hallo,
ich weiss jetzt nicht ob ich konkret weiterhelfen kann. Was ich bei so Problemen und wenn Konstruktoren oder Destruktoren fehlen mache: leite doch von TIniFile eine neue Klasse ab und verwende diese. Füge der Klasse jeweils ein Create und Destroy hinzu (mit inherited) und setze einen Breakpoint darauf. Manchmal kam es schon vor, dass man schon früher im Destroy vorbei kam als erwartet. Das spätere Free "knallt" dann zu recht.

[hoika]

Hallo,

Zitat:

131b0573 +12f DynSearchDialog.dll DynamicSearchDialog 602 +29 TFormDynamicSearchDialog.LoadIni

also Zeile 602 in der Unit DynamicSearchDialog.
steht da wirklich das IniFile.Free?


Nun zum Ausklammern:
1. LoadIni: Code komplett ausklammern (erste Zeile ein Exit?)
2. InitSearch: Aufruf von LoadIni ausklammern

[TheSledgeHammer]

Ja, in der Zeile 602 steht exakt das :) Ich hab es auch als Screenshot mal anbei mit geschickt.

Also wenn ich den Code ausklammere, dann wird auch kein Fehler kommen. Ich versteh den Sinn an der Stelle nicht so ganz. Ich mein: was ich nicht aufrufe, macht auch keine Probleme, oder? Was soll denn an der Stelle der Nutzen sein, würdest du mir das mal erläutern?

[Blup]

1.
Wenn Strings zwischen DLL und Anwendung übergeben werden, muss in beiden ShareMem eingetragen und die "ShareMem.dll" mitgeliefert werden.

Alternativ kann man WideString für Parameter und Rückgabewerte verwenden (auch in Records) z.B.

Delphi-Quellcode:

function MyFunctionDDL(AParam: WideString): WideString; stdcall;

Die Speicherwaltung für diese Strings erfolgt automatich durch OleAuth32, die zu Windows gehört.

2.
Wenn in der DLL TForm verwendet wird, enthält die DLL eine komplett eigenständige Kopie der VCL.
Die VCL verwendet ebenfalls globale Variablen, insbesondere "Application".
"Application.Handle" muss vor der Verwendung der VCL in der DLL einmalig gesetzt werden.

Delphi-Quellcode:

{in der DLL, Handle der Anwendung übernehmen}
procedure InitVCL(AHandle: THandle); stdcall;
begin
  Application.Handle := AHandle;
end;
{in der Anwendung, Handle der Anwendung übergeben}
...
InitVCL(Application.Handle);

3.
Der Bugreport zeigt, ShowModal wird rekursiv noch einmal aus LoadIni über ProcessMessages aufgerufen.
Das ist an sich schon nicht zulässig.
Es scheint aber auch das "iniFile" keine lokale Variable der Methode LoadIni ist, wie es eigentlich sein sollte.

[TheSledgeHammer]

Zitat:

Zitat von freimatz (Beitrag 1481600)

Hallo,
ich weiss jetzt nicht ob ich konkret weiterhelfen kann. Was ich bei so Problemen und wenn Konstruktoren oder Destruktoren fehlen mache: leite doch von TIniFile eine neue Klasse ab und verwende diese. Füge der Klasse jeweils ein Create und Destroy hinzu (mit inherited) und setze einen Breakpoint darauf. Manchmal kam es schon vor, dass man schon früher im Destroy vorbei kam als erwartet. Das spätere Free "knallt" dann zu recht.

Aus genau solchen Gründen hab ich mir angewöhnt, Variablen explizit auf NIL zu setzen und im Finally-Block nochmals explizit auf NIL zu prüfen. Die Ini-File-Instanz per se ist nicht das Problem hier. Eher, dass es innerhalb der DLL aufgerufen wird. Wir verwenden System.IniFiles an zig verschiedenen Stellen und noch nie kam es zu einem Fehler dieser Art. Die TForm-Komponente, die jetzt in der DLL ausgelagert ist, war früher in die Applikation mit rein kompiliert. Und in dieser Konstellation hat das jahrelang einwandfrei funktioniert.

[Blup]

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

TObject(nil).Free; // läuft problemlos

[joachimd]

in Deinem Constructor fehlt ein

Delphi-Quellcode:

inherited Create();

sorry .... wurde ja schon angemerkt ....

[TheSledgeHammer]

Um auf Blup's Post separat zu antworten:

1) Ich übergebe keine Strings. Auch keine WideStrings (auch wenn ich das hier das erste mal lese, aber ist logisch), sondern ich verwende PChar-typen. Das wird ja an unterschiedlichen Stellen so empfohlen, nicht zuletzt im Text des Code-Wizards:

Zitat:

Übergeben Sie String-Informationen mit PChar- oder ShortString-Parametern, um die Verwendung von BORLNDMM.DLL zu vermeiden.

2) DAS ist in der Tat interssant und eine komplette Neuheit für mich. ICh hab mich mit dem Thema TForms in DLLs schon einige Zeit befasst, aber DAS hab ich noch nirgends gelesen. Das sollte per se ja auch nicht das Thema sein, das einzubauen, ich hab ja einen "Konstruktor" in der DLL (ist nix anderes als eine Prozedur namens "CreateSearch"). Da hau ich den neuen Parameter mit rein, guter Punkt! Ist das aber dann nachher auch des Rätsels Lösung?

3) Ob du es glaubst oder nicht, es IST eine lokale Variable. Ich poste mal den gesamten Code:

Delphi-Quellcode:

procedure TFormDynamicSearchDialog.LoadIni;
var
  iniFile: TIniFile;
  sec: String;
begin

  if FIniFile <> '' then
  begin

    sec := 'Search';

    iniFile := nil;

    try

      iniFile := TIniFile.Create(FIniFile);

      miSqlLinkCmdAnd.Checked := iniFile.ReadBool(sec, miSqlLinkCmdAnd.Name, true);
      miSqlLinkCmdOr.Checked := iniFile.ReadBool(sec, miSqlLinkCmdOr.Name, false);

      if miSqlLinkCmdAnd.Checked then
        FSqlLinkCmd := slcAnd
      else if miSqlLinkCmdOr.Checked then
        FSqlLinkCmd := slcOr;

      case iniFile.ReadInteger(sec, pcMain.Name, 1) of
        0: tbFavourites.Click;
        1: tbExpert.Click;
        2: tbFavourites.Click;
      end;

    finally
      if iniFile <> nil then
        iniFile.Free;
    end;

  end else
  begin
    // if no INI has been defined, set SQL link command as default here
    miSqlLinkCmdAND.Checked := true;
    FSqlLinkCmd := slcAnd;
  end;

end;

Und bei dem "ShowModal" sollte man sich nicht verwirren lassen :) Das muss ich aber glaub genauer erklären. Im Interface zur Dll (Unit-Name "DynamicSearchDialogDllInterface") gibt es eine Methode, die "ShowModal" heißt. Diese wiederum ruft die aus der DLL exportierte Methode "ShowModal" auf (Unit-Name "DynSearchDialog"). Und in dieser Methode wird dann das tatsächliche "ShowModal" des TForm-Objekts aufgerufen (Unit-Name "DynamicSearchDialog"). D.h. ShowModal wird tatsächlich nur einmal aufgerufen, allerdings gibt es davor noch andere Methoden, die halt exakt so heißen. Hat was mit der Integration zu tun, ich wollte halt nicht, dass alle Entwickler ihren Code anpassen müssen, wenn sie auf die DLL umsteigen wollen; oder zumindest nur ganz gering anpassen müssen :P

[TheSledgeHammer]

Wenn ich da mal noch einen Einfall anmerken dürfte. Ihr seht ja, dass ich die Ini-Datei-Instanz erzeuge, aber dafür einen im klassenweiten Kontext gültigen Wert verwende (FIniFile). Wie verhält sich das bei Ini-File-Objekten, wenn mehrere Instanzen auf ein und dieselbe physische Ini-Datei zugreifen? Wird da intern nur eine gültige Instanz erzeugt (so wie bei Interfaces) oder sind das mehrere Instanzen, deren Dateioperationen über eine Art Mutex synchonisiert werden?

[TheSledgeHammer]

Zitat:

Zitat von Blup (Beitrag 1481608)

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

TObject(nil).Free; // läuft problemlos

Dazu noch ein kleiner Einwurf: ja, für System-Komponenten mag das alles zutreffend sein. Ich vertrete allerdings die Meinung, dass man so viel Routine wie möglich, auf die einfachste Art und Weise wie möglich bekommen soll - keep the common case simple and fast.

Ihr glaubt gar nicht, wie häufig ich schon bei Konstruktor-Aufrufen Exceptions bekommen habe; daher stehen die immer innerhalb des Try-Blocks. Und ich unterscheide nicht zwischen System-Klassen und "eigenen", da wirst ja sonst kirre! Und v.a. bringst du so was keinem Azubi bei ;) Und eine schlechte Idee ist es auch nicht, wenn man Konstruktoren "absichert"; da sind schon die dollsten Sachen bei passiert!

Vorm Destruktor auf NIL zu prüfen, i.O., das sehe ich ein, das mag bei Delphi durchaus so geregelt sein, aber wer aus der C++ Ecke kommt, gewöhnt sich ganz schnell an, Objekte vorm Zerstören auf Gültigkeit zu prüfen :) Und auch hier unterscheide ich nicht: das mach ich im besten Fall immer so, dann kann ich's im Zweifelsfall auch nicht vergessen. Routine, Routine, Routine...

[TheSledgeHammer]

Zitat:

Zitat von Blup (Beitrag 1481604)

2.
Wenn in der DLL TForm verwendet wird, enthält die DLL eine komplett eigenständige Kopie der VCL.
Die VCL verwendet ebenfalls globale Variablen, insbesondere "Application".
"Application.Handle" muss vor der Verwendung der VCL in der DLL einmalig gesetzt werden.

Delphi-Quellcode:

{in der DLL, Handle der Anwendung übernehmen}
procedure InitVCL(AHandle: THandle); stdcall;
begin
  Application.Handle := AHandle;
end;
{in der Anwendung, Handle der Anwendung übergeben}
...
InitVCL(Application.Handle);

Ich hab mir das mal zu Gemüte geführt. Hab das meiner Meinung nach auch korrekt umgesetzt, allerdings kommt jetzt irgendwann im Erstellungsprozess die Exception
Exception-Klasse EOSError mit Meldung
System Error. Code 1400. Ungültiges Fensterhandle.

Application war auch zu Beginn nicht verfügbar, da die Unit Vcl.Forms nicht eingebunden war. Ich möchte jetzt sicher gehen, dass ich das korrekt verstanden hab: das soll schon in der DLL gesetzt werden, richtig? Nicht erst "während" des Konstruktors des eigentlichen TForm-Objekts? Da wäre es meiner Meinung nach nämlich zu spät, aber ich will da lieber nochmal nachfragen. Das sieht jetzt ungefähr so aus:

Delphi-Quellcode:

// In der DLL
procedure CreateSearch({... ;} AHnd: THandle); cdecl;
begin
  Application.Handle := AHnd; // hier ist das ja korrekt oder?
  FDynamicSearchDlg := TFormDynamicSearchDialog.Create({...});  // hier als Parameter wäre zu spät, richtig?
  // usw.
end;

// Im DLL-Interface (-> außerhalb der DLL, in der EXE drinnen sozusagen)
CreateSearch({...;}, Application.Handle);

[jaenicke]

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481618)

Ihr glaubt gar nicht, wie häufig ich schon bei Konstruktor-Aufrufen Exceptions bekommen habe; daher stehen die immer innerhalb des Try-Blocks.

Dadurch zerschießt du dir den Speicher aber. Denn wenn dort eine Exception auftritt, ist die Variable gar nicht initialisiert. Es wird also ein Free auf einer pseudo-zufälligen Speicherstelle aufgerufen...

Du kannst ja außen herum noch einmal ein try..except setzen oder ähnliches, wenn du die Fehlerursache im Konstruktor nicht abstellen kannst, aber beim try..finally darf die Erstellung des Objekts aus dem genannten Grund nicht im try-Block stehen.

[TheSledgeHammer]

Zitat:

Zitat von jaenicke (Beitrag 1481622)

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481618)

Ihr glaubt gar nicht, wie häufig ich schon bei Konstruktor-Aufrufen Exceptions bekommen habe; daher stehen die immer innerhalb des Try-Blocks.

Dadurch zerschießt du dir den Speicher aber. Denn wenn dort eine Exception auftritt, ist die Variable gar nicht initialisiert. Es wird also ein Free auf einer pseudo-zufälligen Speicherstelle aufgerufen...

Du kannst ja außen herum noch einmal ein try..except setzen oder ähnliches, wenn du die Fehlerursache im Konstruktor nicht abstellen kannst, aber beim try..finally darf die Erstellung des Objekts aus dem genannten Grund nicht im try-Block stehen.

Aus diesem Grund setze ich die Variable zuvor auf NIL, in der Annahme, dass die Zuweisung der Variable ebenfalls unterbrochen wird, wenn eine Exception im Konstruktor-Prozess ausgelöst wird. In diesem Fall sollte aber sowieso der innere Check von "Free" einschreiten, das hatten wir ja zuvor schon ;) Ist halt doppelt abgesichert :)

Das was du jetzt erwähnst, würde ja bedeuten, dass der "eigene" Konstruktor zwar abgebrochen würde, der vom TObject aber nicht. Wie himitsu in einem vorherigen Post erläutert hat, beginnt die Erzeugung des TObjects tatsächlich ja schon vor dem "begin". D.h. "eigene" Klassen machen nach dem

Delphi-Quellcode:

inherited Create

noch eigenes Zeug, was dann u.U. eine Exception auslöst. Wenn das passiert, wird doch dann ein Memory Leak existieren, oder? Ich muss also, um diesen Leak zu eliminieren, irgendwo ein Free aufrufen, damit zumindest das TObject (und je nach Vererbung auch alle höheren Instanzen) wieder sauber zerstört wird.

[Blup]

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481621)

Application war auch zu Beginn nicht verfügbar, da die Unit Vcl.Forms nicht eingebunden war. Ich möchte jetzt sicher gehen, dass ich das korrekt verstanden hab: das soll schon in der DLL gesetzt werden, richtig? Nicht erst "während" des Konstruktors des eigentlichen TForm-Objekts? Da wäre es meiner Meinung nach nämlich zu spät, aber ich will da lieber nochmal nachfragen. Das sieht jetzt ungefähr so aus:

Delphi-Quellcode:

// In der DLL
procedure CreateSearch({... ;} AHnd: THandle); cdecl;
begin
  Application.Handle := AHnd; // hier ist das ja korrekt oder?
  FDynamicSearchDlg := TFormDynamicSearchDialog.Create({...});  // hier als Parameter wäre zu spät, richtig?
  // usw.
end;

// Im DLL-Interface (-> außerhalb der DLL, in der EXE drinnen sozusagen)
CreateSearch({...;}, Application.Handle);

Ja im Prinzip hab ich das so gedacht. Die Initialisierung kann aber erst erfolgen, wenn die Applikarion schon läuft (Hauptfenster erzeugt ist).
Da dein Formular von TForm abgeleitet ist, muss die Unit Forms zumindest da schon eingebunden sein.
http://docwiki.embarcadero.com/Libra...ication.Handle

Modale Formulare vorher zu erzeugen und nur bei Bedarf anzuzeigen ist in der Regel nicht sinnvoll.
Diese werden häufig nach diesem Schema benutzt:

Delphi-Quellcode:

procedure ShowMyDialogForm(var AMyData: TMyData): Boolean;
var
  F: TMyDialogForm; // globale Variable ist für Dialoge nicht erforderlich
begin
  F := TMyDialogForm.Create(nil); // Owner = nil, wir übernehmen selbst die Freigabe des Dialogs
  try
    {Daten übergeben zur Anzeige/Bearbeitung z.B.}
    F.Data := Copy(AMyData);

    Result := (F.ShowModal = mrOk);

    {geänderte Daten übernehmen}
    if Result then
      AMyData := Copy(F.Data);
  finally
    F.Free;
  end;
end;

Wenn tatsächlich im Contructor ein Fehler auftreten kann, sollte man das zusätzllich mit try..except absichern.
F wird dann nicht zugewiesen und der Resourcenschutzblock try..finally komplett nicht durchlaufen.
Man solllte Objekte immer auf der Ebene freigeben, wo diese auch erzeigt wurden, insbesondere aber nur an einer Stelle.

[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.

Rückgabewerte aus der DLL als PChar sind problematisch. Solange der Rückgabewert auf eine Constante oder einen Resourcestring verweist, ist das ok.

Delphi-Quellcode:

function MyDLLFunction(): PChar;
const
  sc = 'ConstText';
var
  s: string;
begin
  s := MyInternFunction;
  Result := PChar(s); // unzulässig da "s" nach verlassen der Funktion eventuell nicht mehr existiert
  // <- wenn Referenzzähler von s auf 0 fällt, wird der String freigegeben, Result enthält einen ungültiger Zeiger

  s := sc;
  Result := PChar(s); // zulässig da "s" auf eine Konstante verweist
  // Referenzzähler von String-Konstanten ist immer -1
end;

[dummzeuch]

Zitat:

Zitat von Blup (Beitrag 1481640)

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.

[jaenicke]

Kannst du vielleicht ein Beispielprojekt erstellen, das nur die DLL-Funktion aufruft? Wenn dann der Fehler noch passiert, kannst du ja vielleicht alles aus der DLL herauswerfen, das du nicht posten möchtest, solange der Fehler noch auftritt.
Denn mit einem funktionierenden Beispiel ließe sich das Problem hier sicher ganz schnell lösen.

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481624)

Wenn das passiert, wird doch dann ein Memory Leak existieren, oder? Ich muss also, um diesen Leak zu eliminieren, irgendwo ein Free aufrufen, damit zumindest das TObject (und je nach Vererbung auch alle höheren Instanzen) wieder sauber zerstört wird.

Ja, das ist ein Memory Leak, aber dagegen kannst du nichts tun. Wie gesagt: Wenn eine Exception im Konstruktor auftritt, wird der Variable nichts zugewiesen und sie ist dann, wenn sie vorher wie du geschrieben hast initialisiert wurde, schlicht nil. Wenn du es aber vergisst, gibt es Probleme.

Der Vorteil, den du in diesem Konstrukt siehst, ist zwar nachvollziehbar, kann aber in der Realität nie (!) eintreten.

Deshalb sollte man sich besser an den Standard halten. Der hat schon seinen Sinn.

[TheSledgeHammer]

Zitat:

Zitat von Blup (Beitrag 1481636)

Ja im Prinzip hab ich das so gedacht. Die Initialisierung kann aber erst erfolgen, wenn die Applikarion schon läuft (Hauptfenster erzeugt ist).
Da dein Formular von TForm abgeleitet ist, muss die Unit Forms zumindest da schon eingebunden sein.
http://docwiki.embarcadero.com/Libra...ication.Handle

Also nur, damit ich das klarstelle: wenn ich den Erben einer TForm-Klasse (hier das Objekt TFormDynamicSearchDialog) erzeuge, brauche ich keine Unit Vcl.Forms einbinden; das geht auch ohne. In derjenigen Unit, wo ich die Klasse TFormDynamicSearchDialog allerdings implementiere, da brauche ich das natürlich, sonst kennt Delphi ja den Typ TForm nicht.

Ich hab jetzt aber dort, wo ich den Erben von TForm instanziiere, das Obkekt Application verwenden sollen und da brauchte ich bisher die Unit Vcl.Forms noch nicht. Daher hab ich sie jetzt erst eingebunden. Aber wie ich ja sagte: ich erhalte eine invalid handle value Exception. Und das während der Konstruktion des Objekts TFormDynamicSearchDialog. Ich glaub es war bei der Erzeugung des PageControl-Components, bin mir aber nicht mehr sicher. Was mache ich denn jetzt damit? Die Hauptapplikation ist ja die EXE-Anwendung und die läuft natürlich schon. Oder hast du damit gemeint, dass ich das Handle-Value nach der Erzeugung des Objekts TFormDynamicSearchDialog erst setzen soll?

Zitat:

Zitat von Blup (Beitrag 1481636)

Modale Formulare vorher zu erzeugen und nur bei Bedarf anzuzeigen ist in der Regel nicht sinnvoll.
Diese werden häufig nach diesem Schema benutzt:

Delphi-Quellcode:

procedure ShowMyDialogForm(var AMyData: TMyData): Boolean;
var
  F: TMyDialogForm; // globale Variable ist für Dialoge nicht erforderlich
begin
  F := TMyDialogForm.Create(nil); // Owner = nil, wir übernehmen selbst die Freigabe des Dialogs
  try
    {Daten übergeben zur Anzeige/Bearbeitung z.B.}
    F.Data := Copy(AMyData);

    Result := (F.ShowModal = mrOk);

    {geänderte Daten übernehmen}
    if Result then
      AMyData := Copy(F.Data);
  finally
    F.Free;
  end;
end;

Exakt! Und dieses Schema bilde ich heute schon in der EXE-Anwendung nach. Dort steht es exakt so, wie du es im Beispiel gezeigt hast. Jetzt wurde aber das Objekt in eine DLL verlagert und da ich ja nicht wollte, dass meine Kollegen zu viel Code anpassen müssen, hab ich die einzelnen Methoden in der DLL abgebildet. D.h. um in deinem Beispiel zu bleiben gibt es einen Konstruktor, einen Destruktor, ein ShowModal und eine Property; letztere gibt es natürlich nur im Interface zur DLL, die DLL selbst exportiert dann natürlich eine Setter- und Getter-Methode. Daher steht das "Create" getrennt von dem "ShowModal", was die DLL angeht. Aber das ist ja nichts, was man jetzt nicht machen darf. Eine neue Komponente würde ich so natürlich nicht programmieren, da gäbe es dann eine Art "CreateAndShow"-Methode oder so.

[TheSledgeHammer]

Zitat:

Zitat von Blup (Beitrag 1481640)

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.

Rückgabewerte aus der DLL als PChar sind problematisch. Solange der Rückgabewert auf eine Constante oder einen Resourcestring verweist, ist das ok.

Delphi-Quellcode:

function MyDLLFunction(): PChar;
const
  sc = 'ConstText';
var
  s: string;
begin
  s := MyInternFunction;
  Result := PChar(s); // unzulässig da "s" nach verlassen der Funktion eventuell nicht mehr existiert
  // <- wenn Referenzzähler von s auf 0 fällt, wird der String freigegeben, Result enthält einen ungültiger Zeiger

  s := sc;
  Result := PChar(s); // zulässig da "s" auf eine Konstante verweist
  // Referenzzähler von String-Konstanten ist immer -1
end;

Also hier gibt es keine Probleme. Ich caste alles entsprechend, so wie dummzeuch es ja beschrieben hat. I.d.R. werden aber die PChar-Variablen unverändert einfach durch gereicht, von daher gibt es hier auch keine Veränderungen. Aber sollte es in einem anderen Fall dazu kommen, wird natürlich eine lokale Kopie erzeugt und mit der weiter gearbeitet.

[DasWolf]

Zitat:

Zitat von Blup (Beitrag 1481608)

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

TObject(nil).Free; // läuft problemlos

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

[Uwe Raabe]

Zitat:

Zitat von DasWolf (Beitrag 1481673)

Zitat:

Zitat von Blup (Beitrag 1481608)

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

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:

Zitat von Dalai (Beitrag 1481678)

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:

Zitat von Uwe Raabe (Beitrag 1481674)

Zitat:

Zitat von DasWolf (Beitrag 1481673)

Zitat:

Zitat von Blup (Beitrag 1481608)

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von dummzeuch (Beitrag 1481650)

Zitat:

Zitat von Blup (Beitrag 1481640)

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:

Zitat von DasWolf (Beitrag 1481742)

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:

Zitat von DasWolf (Beitrag 1481673)

Zitat:

Zitat von Blup (Beitrag 1481608)

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.

Delphi-Quellcode:

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)