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.