EAccessViolation nur manchmal

Braunstein

Um die Fragestunde noch etwas weiterzuführen. Was übergibst du denn als Owner?
Dieser ist ja für das Löschen des Objekts zuständig, so das da schon das Problem liegen kann.
Setze doch einfach mal einen Breakpoint in den Destruktor deines Objektes und schau wann es freigegeben wird.

Es kann sein, das du dein Objekt bereits freigegeben hast, wenn du hasOwner aufrufst. dann zeigt der this Zeiger auf einen ungültigen Speicherbereich. Wenn du dann noch durch die Methode hasOwner auf das ebenfalls ungültige belongsTo zugreifst, dann "knallt" es.

Wie kann ich das verhindern? bzw. wie prüfe ich das?

Den Member belongsTo solltest du übrigens im Konstruktor immer mit NULL vorbesetzen, es sei denn, dieser Wert wird garantiert immer irgendwie zugewiesen.

Wird im Konstruktor initialisiert

Was ich allerdings nicht verstehe: hasOwner liefert bei dir true, wenn der Besitzer NULL ist. Dann ist der Besiter ein NULL-Objekt?

Nein, da ist ein Fehler beim Einfügen im Forum passiert. Ich habe den Code auf das Wesentliche gekürzt. Es muss != statt == heißen.

Um die Fragestunde noch etwas weiterzuführen. Was übergibst du denn als Owner?

in this->belongsTo ist immer ein Zeiger auf ein Objekt, dessen Klasse von Besitzer abgeleitet ist. Mit dem Owner, den TLabel benötigt, hat das aber nix zu tun.

Setze doch einfach mal einen Breakpoint in den Destruktor deines Objektes und schau wann es freigegeben wird.

Gute Idee!
Reicht ein ShowMessage("test") aus oder gibt es im Destruktor besondere Regeln zu beachten?

MfG
Peter

audacia

PeterAcht schrieb:

Setze doch einfach mal einen Breakpoint in den Destruktor deines Objektes und schau wann es freigegeben wird.

Gute Idee!
Reicht ein ShowMessage("test") aus

Was hast du gegen einen Breakpoint?

Braunstein

PeterAcht schrieb:

Mit dem Owner, den TLabel benötigt, hat das aber nix zu tun.

Dann würde ich die Funktion hasOwner() aber umbenennen. Das stiftet sonst Verwirrung.

Mich stört der Name nicht

Also ich habe jetzt einen Breakpoint im Destruktor gesetzt.
Aber der wird nie erreicht. hasOwner verursacht den Fehler wahrscheinlich vorher schon.

Was könnte ich jetzt tun?

akari

Hallo

Dein Quellcode und deine Beschreibung reichen für uns überhaupt nicht aus, um diesen Fehler genau benennen zu können. Zum Beispiel die Frage, ob hasOwner() überhaupt für eine gültige Instanz von Ground aufgerufen wird, ist für uns nicht überprüfbar. Und um genau solche Fragen zu klären gibt es den Debugger. Also setzt ihn ein.

bis bald
akari

audacia

PeterAcht schrieb:

Was könnte ich jetzt tun?

Das Übliche: Call-Stack analysieren, Breakpoints so setzen, daß du in die AV hineinsteppen kannst.

Ob ihrs glaubt oder nicht. Ich hab den Fehler jetzt mit etlichen ShowMessages() eingegrenzt. Mit dem Debugger kenn ich mich einfach zu wenig aus.

Und das Problem war folgendes:

Ich habe eine Methode, die einen Pointer auf ein Objekt der "Problemklasse" übergeben bekommt. Dieser Pointer kann aber auch NULL sein. Und genau dann, wenn er NULL war, kam es zu diesem Problem.

Jetzt muss ich nur noch eine Lösung finden.

Peter

asc

PeterAcht schrieb:

Mit dem Debugger kenn ich mich einfach zu wenig aus.

Das solltest du dringend ändern. Ohne Debugger ist die Fehlersuche meist so Aufwendig wie die Suche nach der Nadel im Heuhaufen...

Ja, das hab ich gemerkt.

Ich arbeite mich mal ein wenig ein.

Braunstein

Das hier könnte helfen
http://www.junix.ch/bcb/help/debug.html

Danke für den Link!
Ich schau mir das mal an, wenn ich wieder Debuggen muss (also jetzt)