Anwendung dereferenziert Nullzeiger, keine Exception

[Der schöne Günther]

Ich bin eigentlich gewöhnt eine Zugriffsverletzung zu bekommen wenn man einen Nullzeiger dereferenziert. Ich habe hier bei einer Anwendung folgenden Stack:

Code:

Der.schöne.Günther.getMode
Der.schöne.Günther.HandleTimer($7F180520)
Vcl.ExtCtrls.TTimer.Timer
Vcl.ExtCtrls.TTimer.WndProc(???)
System.Classes.StdWndProc(987140,275,1,0)
:74d948eb user32.AddClipboardFormatListener + 0x4b
:74d7613c ; C:\WINDOWS\SysWOW64\user32.dll
:74d7528e ; C:\WINDOWS\SysWOW64\user32.dll
:74d75070 user32.DispatchMessageW + 0x10
Vcl.Forms.TApplication.ProcessMessage(???)

Ein Vcl-Timer ruft eine Methode auf, diese Methode sieht so aus:

Delphi-Quellcode:

function TGünther.getMode(): TGüntherMode;
begin
   Result := TGüntherMode.unknown;
   case someReference.someInteger of
      123:   Result := TGüntherMode.Romantisch;
      456:   Result := TGüntherMode.Draufgängerisch;
   end;
end;

Die Variable

Delphi-Quellcode:

someReference

ist eindeutig

Delphi-Quellcode:

nil

. Das sagt auch der Debugger. Trotzdem sagt mir der Debugger auch ohne zu Murren was

Delphi-Quellcode:

someReference.someInteger

sein soll. Die eigentliche Anwendung auch, sie läuft ohne Probleme durch das case-Statement.

Warum ist das so? Wie kann das sein? Und wie bekomme ich so etwas nachgestellt? In einem neuen Projekt bekomme ich erwartungsgemäß eine AV.

[Uwe Raabe]

Es wäre noch interessant, was someReference eigentlich ist und welcher Code sich hinter someInteger verbirgt.

[Blup]

Eine Zugriffsverletzung wird nur ausgelöst, wenn die Methode "someInteger" virtuell ist oder innerhalb der Methode auf "Self" zugegriffen wird.

Delphi-Quellcode:

TMyObject = class(TObject)
private
  FInt2: Integer;
public
  function someInteger1: Integer;
  function someInteger2: Integer;
  function someInteger3: Integer; virtual;
end;

implementation

function TMyObject.someInteger1: Integer;
begin
  Result := 1;
end;

function TMyObject.someInteger2: Integer;
begin
  Result := FInt2; { Self.FInt2 }
end;

function TMyObject.someInteger3: Integer;
begin
  Result := 3;
end;


var
  MyObject: TMyObject;
  v: Integer;
begin
  MyObject := nil;
  v := MyObject.someInteger1;
  v := MyObject.someInteger2; {hier Zugriffsverletzung Self.FInt2}
  v := MyObject.someInteger3; {hier Zugriffsverletzung Self.ClassType.Methode}
end;

[Der schöne Günther]

Aber ...

Delphi-Quellcode:

someInteger

ist ... ein Integer. Eine Variable. Keine Methode. Sonst hätte ich auch

Delphi-Quellcode:

getSomeInteger()

geschrieben ;-)

[Uwe Raabe]

Jetzt wäre halt wirklich mal die Deklaration dieser Klasse von someReference interessant...

[Der schöne Günther]

Alles klar. Es ist mir fast peinlich, aber es ist eine globale Variable auf eine TForm (VCL). Dieses Formular ist ein riesiges Spaghetti-Konstrukt mit

Delphi-Quellcode:

message

-Direktiven wie

Delphi-Quellcode:

procedure WMQUERYENDSESSION(var msg: TWMQueryEndSession); message WM_QUERYENDSESSION;

. Als das Ding entstand ging ich ehrlich noch in die Grundschule.

Ich bekomme es mit einer neuen TForm nicht nachgestellt.

Und noch eine Sache: Im Debugger ist immer alles gut, keine Exception, der Nullzeiger wird dereferenziert. Führe ich die exakt gleiche Exe direkt aus (also nicht aus der IDE), kommt es normal zur erwarteten Exception.

PS:

Delphi-Quellcode:

InstanceSize

dieses Formulars liefert 149220 (!)

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1449346)

PS:

Delphi-Quellcode:

InstanceSize

dieses Formulars liefert 149220 (!)

Dann liegt der Offset für den besagten Integer vermutlich außerhalb des gefährdeten Bereichs - zumindest beim Debugging.

[Der schöne Günther]

Was ist ein gefährdeter Bereich? Und wie wirkt sich das Debugging darauf aus? Ich kenne mich mit den ganzen LowLevel-Sachen nicht aus...

Meinst du dass er sich den Zeigerwert (Null) nimmt, darauf addiert wo der entsprechende Integer sein müsste, und der resultierende Wert ist bereits so groß dass das Betriebssystem meint "Jo, da darf der Knilch lesen"? Aber warum hätte ein laufender Debugger darauf Einfluss? Merkwürdig...

PS: Auch der Einsatz des "FullDebugMode" von FastMM4 bringt keine Änderungen mit sich.

[Uwe Raabe]

Ob dein Programm bzw. die IDE von einem bestimmten, absolutem Speicherbereich lesen darf hängt von der aktuellen Situation ab, und diese kann sich durch den Debugger ändern. Es ist als eher Zufall ob es dabei knallt oder nicht.

[Der schöne Günther]

Das ist ja wirklich unbefriedigend.

Zumal ich es auch nicht nachgestellt bekomme wenn ich meinen Referenztyp (TForm oder TObject oder was auch immer) soweit aufblase dass die

Delphi-Quellcode:

InstanceSize

gleich ist.

Im Debugger kommt nie eine Zugriffsverletzung, ohne Debugger kommt immer eine. Ich habe in den Projektoptionen nichts gefunden was das irgendwie noch beinflussen könnte...

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1449363)

Zumal ich es auch nicht nachgestellt bekomme wenn ich meinen Referenztyp (TForm oder TObject oder was auch immer) soweit aufblase dass die

Delphi-Quellcode:

InstanceSize

gleich ist.

Steht denn dann auch der Integer an derselben Stelle? Andererseits bedeutet ein anderes Programm auch ein anderes Memory-Layout. Ich würde also immer noch Zufall anführen, wobei Zufall in der Programmierung ja eigentlich nicht existiert. Sagen wir also, die Zusammenhänge sind so komplex, daß es schwierig ist, sie konsistent nachzubilden.

[Der schöne Günther]

Mein Nachstellen beschränkte sich auf ein TObject das mit einem statischen Byte-Array von 0 bis 149216 beginnt und danach ein Integer kommt. Also nein, exakt die gleiche Stelle wäre es jetzt nicht gewesen.

Das kann ich auch noch einmal versuchen exakt nachzubilden, aber was weiß ich schon wo der Compiler wirklich die Felder hinlegt? Vielleicht wird da etwas optimiert und hin- und hergeschoben. Vielleicht kann man so etwas im CPU-Fenster bzw. Assemblercode sehen, aber für mich ist das nur Zeichensalat.

[Uwe Raabe]

Man muss sich halt fragen, ob das überhaupt zu was führt. Wenn eine Objekt-Instanz nil ist, dann kann man ja eh keine vernünftigen Daten in den Feldern erwarten - unabhängig davon, ob der Zugriff erlaubt ist oder nicht. Dasselbe gilt ja auch für eine bereits freigegebene Instanz, die aber immer noch auf den alten Speicherbereich zeigt. Da kann aber mittlerweile ja schon was anderes reingeschrieben worden sein.

[Der schöne Günther]

Richtig, da ist nur Schrott drin.

Mein Problem ist dass im Debugger keine Exception auftritt obwohl es keinen Grund gibt (der sich mir erschließt) weshalb es nicht knallen sollte.

Auf jeden Fall vielen Dank für deine Hilfe.