Schutzverletzung bei Zugriff auf Objekt

[cltom]

Hallo,

nach mehrstündiger Suche hab ich noch immer keinen Deut und hoffe auf Hinweise:

Der Fehler ist eine Schutzverletzung, sobald ich auf ein objekt zugreife. Eine Prüfung "if assigned(sd)" nutzt nichts, da geht er darüber.

Das Objekt selber ist in eine andere Klasse gepackt. Sinngemäß sieht das so aus:

Delphi-Quellcode:

  ObjektA.ObjektB.ParameterA := s;
  ObjektA.ProzedurX;
  ObjektA.ProzedurY;

procedure ProzedurX;
begin
  ObjektB.ParameterB := x;
end;

procedure ProzedurY;
begin
  ObjektB.ParameterB := y;
end;

naturgemäß ist das nicht der Originalcode. Komisch nun ist, dass ProzedurX klappt, ProzedurY nicht. Beide machen nicht mehr, als auf das eingebettete Objekt zuzugreifen. Erzeugt wird das ObjektB im Create von ObjektA. Und ich kann auch darauf zugreifen, etwa in Prozedur X, aber auch von aussen (aus dem mainform), nur nicht aus ProzedurY heraus.

Mir ist klar, dass man damit noch keine Lösung ableiten kann, aber gleich alle Klassen posten ist halt auch nicht einfacher.

danke für Hinweise, wo ich suchen könnte

gruß
tom

[cltom]

ps. Wenn ich die beiden Klassen herausziehe und in ein leeres Testprojekt stecke, dann klappen übrigens auch die beiden Prozedur-Aufrufe, es muss also irgendeine Querabhängigkeit sein.

Hmm, ich weiss, damit wird man nicht schlauer ...

[baumina]

Zitat:

Zitat von cltom (Beitrag 1217454)

Mir ist klar, dass man damit noch keine Lösung ableiten kann, aber gleich alle Klassen posten ist halt auch nicht einfacher.

Ja, anhand des geposteten Codes kann man leider gar nichts erkennen. Außer dass wohl ProcedureX nicht innerhalb des Objects ist (procedure TObjektA.ProcedureX).

Schutzverletzungen treten meist auf, wenn man auf etwas zugreifen will, das NIL ist.

[DeddyH]

Da die Assigned()-Prüfungen nicht greifen, scheint das Objekt ja nicht einmal NIL zu sein. Es hat den Anschein, dass es irgendwann vorher freigegeben, aber eben nicht genullt wurde, so dass man auf einen Dangling Pointer zugreift. So etwas ist oft schwer zu finden.

[Blup]

Insbesondere wenn mehrere Variablen das selbe Objekt referenzieren können, bei der Freigabe aufpassen.
Warnungen im Compiler einschalten, insbesondere eventuell nicht initialisierte Variablen.
Allgemein Objekt.Free durch FreeAndNil(Objekt) ersetzen.
Einen Breakpoint im Konstruktor und Destruktor der betreffenden Klasse setzen.
Jeder Instanz eine fortlaufende Nummer geben und die Erzeugung, Freigabe und Zuweisung auf die Variable(n) an der Fehlerstelle protokollieren.

[cltom]

Danke schon mal für die Antworten. Das Komische ist, dass ich knapp vorher noch auf das Objekt zugreifen kann.

Delphi-Quellcode:

//main form
  objekta.objektb.value_a := 123.0;
  if somecondition then
    objekta.prozedurx
  else
    objekta.prozedury;

//TKlasseA
procedure TKlasseA.prozedurx;
begin
  objektb.value_b := 456; //geht
end;

procedure TKlasseA.prozedury;
begin
  objektb.value_b := 456; //geht nicht
end;

In der main Form kann ich auf das Objekt B zugreifen. Ich schreib Werte rein, und kann - wenn ich Breakpoints setze - auch das Objekt und seine Werte sehen. Und dann kommt eine simple Abfrage, die entscheidet, ob Prozedur X oder Prozedur Y ausgeführt wird. Wenn X ausgeführt wird, dann existiert das Objekt, ich kann via Breakpoint das Objekt und seine Werte einsehen, wenn Y ausgeführt wird, scheint das Objekt wie verschwunden, aber eben auch nicht NIL.

Objekt B wird übrigens erst im destructor von Objekt A mit FreeAndNil freigegeben. Da komme ich aber nie hin. Und wie erwähnt, wenn ich genau das gleiche in einem neuen Testprojekte mache, dann funktioniert es auch. Es muss offenbar irgendeine merkwürdige Quer-Abhängigkeit sein.

Das Objekt A wird auch nur ein mal erzeugt, nämlich im Create des Forms. Von der KlasseB werden allerdings in drei weiteren anderen Klassen Instanzen erzeugt. Kann da der Hund begraben liegen? Ist es entscheidend, wie ich die Klasse B in verschiedenen anderen Klassen instanziere? Das muss doch egal sein, oder?

Danke jedenfalls für Eure Aufmerksamkeit!

[baumina]

Kann es denn sein, dass Du in dem Objekt irgendwas mit dem Speicher anstellst (getmem/freemem, dynamische Arrayzuweisungen, Pointerzugriffe etc.) und du damit vielleicht was im Speicher versehentlich überschreibst, das würde erklären warum ein "leeres" Projekt geht und dein anderes nicht?

[cltom]

mit der Instanz der KlasseB mache ich sonst nichts dergleichen. Auch sonst im Projekt, in anderen Instanzen dieses Objekts habe ich keine Pointer, getmen/freemem, ...).

Was ich probiert habe, den Inhalt der ProzedureX nach Y zu kopieren. Das klappt auch nicht. Selbst wenn die ProzedurY genau den gleichen Inhalt hat, gibts die Schutzverletzung. So, als ob beim Aufruf dieser Prozedur das Objekt verschwindet. Hab auch mal eine neue Prozedur angegelegt (KlasseA.ProzedurZ) und den Inhalt von Y reinkopiert. Geht auch nicht.

Ich könnte mal testweise alle anderen Instanzen von KlasseB weglassen. Aber dann funktioniert das Projekt de facto nicht mehr, da müsste ich praktisch alles auskommentieren, was das Ding macht.

[Blup]

Ist eine der Methoden X,Y,Z virtuell?
Das würde darauf hindeuten das die Variable "objekta" nicht auf eine gültige Instanze der Klasse TKlasseA verweist.

Da der Fehler nur in deinem Projekt auftritt, lässt sich die Ursache auch nur im konkreten Code eingrenzen.
Ohne Quellcode, mit dem man den Fehler reproduzieren kann, sind nur allgemeine Hinweise möglich.
Bei dem geposteten abstrakten Code fehlen einfach zu viele Details.

[sx2008]

Wenn du Zugriffsverletzungen in Methoden hast und den Fehler nicht finden kannst ist folgender Trick empfehlenswert:

Delphi-Quellcode:

procedure TKlasseA.prozedury;
begin
  Assert(Assigned(self));     // Sicherheitsprüfung
  Assert(Assigned(objektb));  // 2. Sicherheitsprüfung
  objektb.value_b := 456; //geht nicht
end;

In den Projektoptionen müssen die Asserts eingeschaltet sein.
Durch

Delphi-Quellcode:

Assert(Assigned(self))

wird sichergestellt, dass das Objekt in dem man aktuell arbeitet auch angelegt ist.
Wird die Assertion ausgelöst, bekommt du die Unit und die Zeilennummer an dem das Problem entdeckt wurde.