Sporadische Zugriffsverletzungen

[TiGü]

Auch wenn da ganz viel im Argen ist, konzentrieren wir uns mal auf das Wesentliche.

Schließe das Speicherleck in TfrmMain.NeuKunde .
Du erzeugst k:=TKunde.Create; , gibst aber nur frei, wenn der Kunde schon existiert.
Es würde wohl reichen, wenn du am Schluss einfach Kunden.Add(K) aufrufen würdest.
Dann kannst du dir das Kunden.LoadFromDirector(DataBaseDir); auch sparen.

[Hobbycoder]

Okay, da habe ich vergessen, k wieder freizugeben, oder aber eben Tkunden.Add(k) und mir das Load sparen.
Gibt sicherlich auch bessere Varianten, das zu lösen. Wo nun aber ganz viel im Argen ist, kann ich so nicht nachvollziehen.

Leider hat das auch nichts mit dem Problem zu tun, da die Zugriffsverletzung auch ohne hinzufügen eines neuen Kunden kommt. Aber halt eben nicht immer.
Mein Fehler muss irgendwo zwischen dem Erzeugen der Nodes und dem GetText liegen, denn wenn ich beide Proceduren durchsteppe kommt der Fehler nach BuildList und vor GetText.

[Klaus01]

.. auch wenn ich mich jetzt unbeliebt mache..
Wo sind die Unit-Tests?

Grüße
Klaus

[TiGü]

Welche Version des Virtual Treeviews verwendest du denn eigentlich genau?
Kannst du bspw. in der Unit VirtualTrees.pas in der Konstante VTVersion sehen (um die Zeile 100 herum).

[jaenicke]

Zitat von Hobbycoder:

Mein Fehler muss irgendwo zwischen dem Erzeugen der Nodes und dem GetText liegen, denn wenn ich beide Proceduren durchsteppe kommt der Fehler nach BuildList und vor GetText.

Wie sieht denn der Stacktrace an der Stelle aus?

[Hobbycoder]

Zitat von TiGü:

Welche Version des Virtual Treeviews verwendest du denn eigentlich genau?
Kannst du bspw. in der Unit VirtualTrees.pas in der Konstante VTVersion sehen (um die Zeile 100 herum).

VTVersion = '6.6.0';

Zitat von jaenicke:

Zitat von Hobbycoder:

Mein Fehler muss irgendwo zwischen dem Erzeugen der Nodes und dem GetText liegen, denn wenn ich beide Proceduren durchsteppe kommt der Fehler nach BuildList und vor GetText.

Wie sieht denn der Stacktrace an der Stelle aus?

Siehe Screenshots im Anhang. Zu Beachten sei an dieser Stelle im Screenshot MadExcept2.png die Zeilennummern, die bei der Unit u_daten ausgegeben werden. Diese u_daten hat gar nicht so viele Zeilen.

MadExcept1.pnp tritt auf, wenn ich vom aus der ersten Ansicht, wo im Treeview lediglich die Kundendaten stehen, einen Eintrag mittels NodeDblClick öffne und die Detaildaten angezeigt werden sollen. Übergehe ich den Fehler, so läuft das Prog ohne Fehler weiter und auch alle danach erzeugen Nodes sind alle wie gewünscht vorhanden.

MadExcept2.pnp tritt auf, wenn ich dann das Programm beenden will.

[TiGü]

Zitat von Hobbycoder:

Siehe Screenshots im Anhang. Zu Beachten sei an dieser Stelle im Screenshot MadExcept2.png die Zeilennummern, die bei der Unit u_daten ausgegeben werden. Diese u_daten hat gar nicht so viele Zeilen.

Da steht zwar u_daten und Zeile 6703, aber die Funktion ist klar angegeben mit der Notify-Methode der generischen Liste. Und darauf bezieht sich auch die Zeilennummer.
Du wirst wahrscheinlich ein Objekt haben, was aber schon freigegeben ist - warum gilt es zu untersuchen - und noch als Dangling Pointer in der Liste steckt.
Das Freigeben über den Listenautomatismus oder die Erzeugung von Virtual Nodes aus diesem kaputten Objekt führt dann bei dir dann zu Problemen.

Übrigens kannst du auch ganz wunderbar sowas schreiben:

if MyObject is TPassword then

anstatt

if MyObject.Classname = TPassword.Classname then

[Luckie]

Was Allgemeines. So sporadische Zugriffsverletzungen deuten drauf hin, dass was mit dem Speicher nicht stimmt. Beispielsweise wurde ein Objekt freigegeben, auf das dann aber noch zugegriffen wird. Manchmal hat man Glück und die Speicherstelle enthält noch gültige Daten, aber manchmal eben auch nicht und dann kommt es zu einer Zugriffsverletzung. Also untersuche dein Code mal auf solche Situationen hin.

[p80286]

Jetzt fehlt noch der Hinweis auf Bereichsprüfung und Konsorten und die Basis für die Fehlersuche ist gelegt.

Gruß
K-H

[Ralf Kaiser]

Zitat von Luckie:

Beispielsweise wurde ein Objekt freigegeben, auf das dann aber noch zugegriffen wird. Manchmal hat man Glück und die Speicherstelle enthält noch gültige Daten...

Was den Fehler dann um so schwerer lokalisierbar macht. Wenn z.B. durch Zufall auf dem Entwicklungsrechner immer genug Speicher vorhanden ist und darum der Speicher an der Stelle noch nicht überschrieben wurde taucht der Fehler unter Umständen gar nicht auf. Beim Benutzer, wo eine andere Speichersituation vorliegt knallt es dann sofort.

In einer solchen Situation kann man eigentlich nur mit FastMM im "FullDebug"-Modus einem solchen Problem auf die Spur kommen. Da gibt es die Möglichkeit den Speicher freigegebener Objekte mit einem Bit-Muster überschreiben zu lassen, was dann in dieser Situation das Auffinden des Problems enorm erleichtert. Da knallt es nämlich direkt beim nächsten Zugriff und man sieht im Debugger sofort wo der ungültige Zugriff erfolgte.