Access Violation in TObject.InheritsFrom von "is"-Operator

[dummzeuch]

Zitat von AuronTLG:

Und nur um das das Offensichtliche auszuschließen: "XYZ" ist kein Nullpointer.

Dementsprechend habe ich zwei Merkwürdigkeiten:

1. Dass es bei der Nutzung vom is-Operator überhaupt knallen kann. Es ist ja nicht so dass man dabei irgendwas falsch machen könnte.
2. Dass es nur bei mir auftritt. Wobei ich es sicherheitshalber auch nochmal auf einem anderen PC mit komplett eigener Kompilierung ebenfalls reproduzieren konnte.

Dass es kein NIL-Pointer ist, heißt nicht, dass es ein Pointer auf ein gültiges Objekt ist.

Folgendes knallt auch:

Delphi-Quellcode:

var
  SomeObj: TSomeClass;
begin
  SomeObj := Pointer(5);
  if SomeObj = nil then
    raise Exception.Create('SomeObj ist nil');
  if not (SomeObj is TSomeClass) then
    raise Exception.Create('SomeObj ist kein TSomeClass');
end;

Da $00000005 kein Pointer auf ein TObject ist, knallt es hier auch schon beim Ausführen des IS-Operators.

So einfach wird es in Deinem Fall aber wohl nicht sein, sondern eher sowas wie:

Delphi-Quellcode:

procedure DoSomething(var _Obj: TSomeClass);
begin
  _Obj.Free;
end;

var
  SomeObj: TSomeClass;
begin
  SomeObj := TSomeClass.Create;
  DoSomething(SomeObj);
  if SomeObj = nil then
    raise Exception.Create('SomeObj ist nil');
  if not (SomeObj is TSomeClass) then
    raise Exception.Create('SomeObj ist kein TSomeClass');
end;

Der Pointer zeigt nach Aufruf von DoSomething auf eine inzwischen freigegebene Instanz von TSomeClass. Je nachdem, ob der davon benutzte Speicher in der Zwischenzeit anderweitig verwendet wurde oder nicht, wird der IS-Operator fehlschlagen oder nicht. Ob das der Fall ist, kann von vielen Bedingungen abhängen. Und es kann sein, dass es auf einem Rechner zu einem Fehler führt und auf einem anderen nicht.

Es gibt auch noch andere Möglichkeiten (z.B. irgendwas übeschreibt den Pinter), aber ich dieser Fall ist der wahrscheinlichste.