Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[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

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.

[TheSledgeHammer]

Zitat von 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.

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.
TObject(nil).Free; // läuft problemlos

[joachimd]

in Deinem Constructor fehlt ein
inherited Create(); sorry .... wurde ja schon angemerkt ....

[TheSledgeHammer]

Zitat von Blup:

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
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...

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