AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi Zugriffsverletzung beim Zerstören der TIniFile-Instanz

Zugriffsverletzung beim Zerstören der TIniFile-Instanz

Ein Thema von TheSledgeHammer · begonnen am 26. Jan 2021 · letzter Beitrag vom 3. Feb 2021
Antwort Antwort
Seite 1 von 7  1 23     Letzte » 
TheSledgeHammer

Registriert seit: 22. Mai 2019
Ort: Mulfingen
41 Beiträge
 
Delphi 10.3 Rio
 
#1

Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 15:57
Delphi-Version: 10.3 Rio
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.

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.

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.
Tobias
  Mit Zitat antworten Zitat
Sinspin

Registriert seit: 15. Sep 2008
Ort: Dubai
228 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 16:19
Hallo,

So hat es bei mir noch nie Probleme gegeben:
Delphi-Quellcode:
iniFile := TIniFile.Create(FIniFile);
try
  // ReadBool, ReadString, etc.
finally
  iniFile.Free;
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.
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 inherited; Besonders wenn man langfristig denkt und sich das Verhalten für TObject auch mal ändern könnte.
Stefan
Wir zerstören die Natur und Wälder der Erde. Wir töten wilde Tiere für Trophäen. Wir produzieren Lebewesen als Massenware um sie nach wenigen Monaten zu töten. Jetzt rächt sich die Natur und tötet uns.
  Mit Zitat antworten Zitat
Benutzerbild von dummzeuch
dummzeuch

Registriert seit: 11. Aug 2012
Ort: Essen
956 Beiträge
 
Delphi 2007 Professional
 
#3

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 16:20
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.
Thomas Mueller
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.144 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 16:33
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.286 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 16:36
Wird die Instanz vielleicht aus der DLL noch an ein Executable weitergereicht, oder wird sie rein intern verwendet? Lokale Variable oder globale Variable/Feld?
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.722 Beiträge
 
Delphi 10.4 Sydney
 
#6

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 17:04
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 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 )




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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (26. Jan 2021 um 18:19 Uhr)
  Mit Zitat antworten Zitat
TomyN

Registriert seit: 8. Nov 2006
Ort: Bayreuth
108 Beiträge
 
Delphi 10.3 Rio
 
#7

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 26. Jan 2021, 21:12
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?
Thomas Neumann
Meine Projekte
www.satlive.audio
www.levelcheck.de
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.008 Beiträge
 
Delphi 10.4 Sydney
 
#8

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 07:24
Hallo,
die Signatur der Methode wäre interessant.
Und ich würde mal den kompletten Code auskommentieren,
dann tritt der Fehler wahrscheinlich nicht auf.
Heiko
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.332 Beiträge
 
Delphi 10.4 Sydney
 
#9

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 08:42
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.
  Mit Zitat antworten Zitat
TheSledgeHammer

Registriert seit: 22. Mai 2019
Ort: Mulfingen
41 Beiträge
 
Delphi 10.3 Rio
 
#10

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 08:47
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.
Angehängte Dateien
Dateityp: txt bugreport (002).txt (19,2 KB, 18x aufgerufen)
Tobias
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf