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 2 von 7     12 34     Letzte » 
freimatz

Registriert seit: 20. Mai 2010
1.032 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#11

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 09:57
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.

Geändert von freimatz (27. Jan 2021 um 11:01 Uhr)
  Mit Zitat antworten Zitat
hoika

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 11:29
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
Heiko

Geändert von hoika (27. Jan 2021 um 11:33 Uhr)
  Mit Zitat antworten Zitat
TheSledgeHammer

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 12:04
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?
Miniaturansicht angehängter Grafiken
free.png  
Tobias
  Mit Zitat antworten Zitat
Blup

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 12:07
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.
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.

Geändert von Blup (27. Jan 2021 um 12:09 Uhr)
  Mit Zitat antworten Zitat
TheSledgeHammer

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 12:08
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.
Tobias
  Mit Zitat antworten Zitat
Blup

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 12:28
Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
TObject(nil).Free; // läuft problemlos
  Mit Zitat antworten Zitat
Benutzerbild von joachimd
joachimd

Registriert seit: 17. Feb 2005
Ort: Weitingen
634 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 12:41
in Deinem Constructor fehlt ein
inherited Create(); sorry .... wurde ja schon angemerkt ....
Joachim Dürr
Joachim Dürr Softwareengineering
http://www.jd-engineering.de

Geändert von joachimd (27. Jan 2021 um 13:16 Uhr)
  Mit Zitat antworten Zitat
TheSledgeHammer

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 13:10
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
Tobias

Geändert von TheSledgeHammer (27. Jan 2021 um 13:12 Uhr)
  Mit Zitat antworten Zitat
TheSledgeHammer

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 13:15
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?
Tobias
  Mit Zitat antworten Zitat
TheSledgeHammer

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

AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz

  Alt 27. Jan 2021, 13:33
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...
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 11:00 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