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

markieren

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:

markieren

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 someReference ist eindeutig nil . Das sagt auch der Debugger. Trotzdem sagt mir der Debugger auch ohne zu Murren was 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.

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

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

zusammenfalten · markieren

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;

Aber ... someInteger ist ... ein Integer. Eine Variable. Keine Methode. Sonst hätte ich auch getSomeInteger() geschrieben

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

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 message -Direktiven wie 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: InstanceSize dieses Formulars liefert 149220 (!)

Zitat von Der schöne Günther:

PS: InstanceSize dieses Formulars liefert 149220 (!)

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

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.

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.

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 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...