Announcement

**Hagen Reddmann** · 04.06.2003, 23:44

probiert statt DebugBreak mal

<pre>

asm
INT 3
end;

</pre>

aus.

Gru� Hage

**Ulrich Gerhardt** · 05.06.2003, 08:44

Danke, Hagen. Damit ist schonmal eine der drei Ebenen aus dem Spiel. :-)
 Uli

**Hagen Reddmann** · 05.06.2003, 10:53

Ich sehe gerade, deine Frage ist ja aus 2002, oder stimmt da was nicht ??

Gru� Hage

**Ulrich Gerhardt** · 05.06.2003, 11:36

Doch, stimmt. Ich hatte sie eigentlich auch schon ganz vergessen. Ist sie bei dir als neu aufgetaucht?
 Uli

**Hagen Reddmann** · 05.06.2003, 13:17

Jo, sonst h�tte ich ja nicht geantwortet

)
Deine Frage war ja auch easy zu beantworten. Im Grunde macht der asm part das gleiche wie DebugBreak, bzw. es ist der gleiche code. Mit dem Unterschied das der Code im Modul deiner Anwendung steht und eine Stackebene h�her liegt. Diese zwei Fakten haben aber ein anderes Verhalten des Debuggers zur Folge. 

Welche zwei "Ebenen" verbleiben denn noch ? 
Ich frage weil ich selber schon Probleme, �rgernisse, mit der Assert Behandlung hatte. In D5 scheint der Debugger nicht an der Quelltextposition stehen zu bleiben in der die Assertion steht. 

Gru� Hage

**Ulrich Gerhardt** · 06.06.2003, 10:44

Welche zwei "Ebenen" verbleiben denn noch ? 
Der Debugger steht auf dem "int 3" in meiner AssertErrorProc.
Eine Stackebene h�her kommt das "RET" hinter dem "CALL AssertErrorProc"
in _Assert und noch eins h�her die Zeile hinter dem fehlgeschlagenen
Assert. 
Rufe ich in meiner AssertErrorProc hingegen die (vorher gemerkte)
delphi-eigene AssertErrorProc auf, so stehe ich wie gew�nscht *auf*
der Zeile mit dem b�sen Assert (durch Tricksereien mit ErrorAddr offenbar).
Leider sind dann aber die Werte der lokalen Variablen nicht mehr
erkennbar (aufgrund der geworfenen Exception). 
Dummerweise ist mir nichts eingefallen, wie ich die Vorteile dieser
beiden Varianten gleichzeitig haben kann.

Ich bin mal so frei und h�ng meine bisherigen Ergebnisse an.
Vielleicht siehst du ja irgendwelche offensichtlichen Fehler. :-)
<pre class="sourcecode"><code>
unit ChoiceAssert;
 
interface
 
type
TAssertionBehaviour = (abIgnore, abHalt, abDebug, abUserChoice, abDelphi);
 
procedure InitChoiceAssert(Behaviour: TAssertionBehaviour);
procedure DoneChoiceAssert;
 
implementation
 
uses
Windows,
SysConst,
SysUtils;
 
type
TAssertErrorProc = procedure(const Message, Filename: string;
LineNumber: Integer; ErrorAddr: Pointer);
 
var
AssertionBehaviour: TAssertionBehaviour;
OldAssertErrorProc: TAssertErrorProc;
 
function GetUserChoice(const Message, Filename: string;
LineNumber: Integer; ErrorAddr: Pointer): TAssertionBehaviour;
const
cNewLine = #13#10;
cUserChoiceMsg = '%s' + cNewLine +
'(%s, Zeile %d, Adresse $%x)' + cNewLine +
cNewLine +
'Wollen Sie die Anwendung beenden ("Abbrechen&quot

,' + cNewLine +
'debuggen ("Wiederholen&quot

oder die Assertion ignorieren?';
var
Choice: Integer;
S: string;
begin
S := Format(cUserChoiceMsg,
[Message, Filename, LineNumber, Pred(Integer(ErrorAddr))]);
Choice := Windows.MessageBox(GetForegroundWindow, PChar(S), PChar(SAssertionFailed),
MB_ABORTRETRYIGNORE or MB_ICONERROR);
case Choice of
IDABORT:
Result := abHalt;
IDRETRY:
Result := abDebug;
else //IDIGNORE:
Result := abIgnore;
end;
end;
 
procedure ChoiceAssertErrorHandler(const Message, Filename: string;
LineNumber: Integer; ErrorAddr: Pointer);
var
Behaviour: TAssertionBehaviour;
Choice: Integer;
S: string;
begin
if AssertionBehaviour = abUserChoice then
Behaviour := GetUserChoice(Message, Filename, LineNumber, ErrorAddr)
else
Behaviour := AssertionBehaviour;
 
case Behaviour of
abHalt:
FatalExit(666);
//FatalAppExit(0, 'Hallo!');
abDebug:
//DebugBreak;
asm int 3 end;
abDelphi:
OldAssertErrorProc(Message, Filename, LineNumber, ErrorAddr);
else //abIgnore:
// nix
end;
end;
 
procedure InitChoiceAssert(Behaviour: TAssertionBehaviour);
begin
AssertionBehaviour := Behaviour;
TAssertErrorProc(AssertErrorProc) := ChoiceAssertErrorHandler;
end;
 
procedure DoneChoiceAssert;
begin
TAssertErrorProc(AssertErrorProc) := OldAssertErrorProc;
end;
 
 
initialization
OldAssertErrorProc := AssertErrorProc;
finalization
DoneChoiceAssert;
end.
</code></pre>

(to be continued...

**Ulrich Gerhardt** · 06.06.2003, 10:45

Benuztung ungef�hr so:
<pre class="sourcecode"><code>
// ... [snip] ...
 
procedure TForm1.FormDblClick(Sender: TObject);
var
i: Integer;
begin
i := 666;
Assert(i < 300);
i := i*i;
end;
 
initialization
InitChoiceAssert(abUserChoice);
finalization
DoneChoiceAssert;
end.
</code></pre>

In D5 scheint der Debugger nicht an der Quelltextposition stehen zu bleiben in der die Assertion steht. 
Au�er dem obigen Sch�nheitsfehler f�llt mit grad keine Probleme ein (D5.01 Pro).

Ciao, Uli

**Ulrich Gerhardt** · 06.06.2003, 10:46

Benuztung, f�llt mit grad keine Probleme ein, ...
 �hem..

**Hagen Reddmann** · 06.06.2003, 11:29

Mann m�sste anderes vorgehen. Statt den INT 3 so auszul�sen, m�sste dein Assert Handler den INT 3 Opcode HINTER oder VOR dem CALL zu Assert() plazieren. Der Debugger w�rde dann genau im Stackframe wo die Assert() �berpr�fung stattfindet stehen bleiben.

In D5 scheint der Debugger nicht an der Quelltextposition stehen zu bleiben in der die Assertion steht.
Au�er dem obigen Sch�nheitsfehler f�llt mit grad keine Probleme ein (D5.01 Pro). 

Das stimmt, der Debugger hat in der Berechnungsfunktion f�r den Opcode ein Displacement drinnen. D.h. wenn du mit Exception.Create() at ErrorAddr; arbeitest dann nutzt der Debugger ABH�NGIG von den Optimierungseinstellungen einen +1 Displacement ?!?! 

Er errechnet also die Fehleradresse falsch. 
Kannst dir nicht vorstellen wie ich gekotzt habe. 

Ich hatte ein �hnliches Problem wie Du. In meiner Large Integer Unit nutze ich Exceptions und Assertion() um z.b. eine m�gliche Division durch Null o.�. anzuzeigen. 
Normalerweise bleibt der Debugger an der Stelle stehen WO ich raise aufrufe, deshalb gibts ja "at ErrorAddr". Mein Ziel war nun im Stackframe, auf der Adresse die MEINE Funktion aufgerufen hat zu stehen. D.h. z.B. ruft der Anwender

<pre>

NDiv(A, B); // A := A div B

</pre>

auf, �berpr�fe ich in der Implementierung von NDiv() ob B = 0 ist. Sollte das der Fall sein raise ich eine Exception "Division by Null" aus. Nun sollte der debugger NICHT innerhalb NDiv stehen sondern im obigen Aufruf von NDiv() durch den User Code. !! 

Ich habe dieses Problem nie richtig l�sen k�nnen. Obwohl meine Implemntierung einen Stackframe benutzt hat, scheint der Debugger die "at ErrorAddr" nicht korrekt zu interpretieren. 

Gru� Hage

**Hagen Reddmann** · 06.06.2003, 11:36

F�r dein INT 3 gibts noch eine andere L�sung. 

Statt INT3 l�sst du eine "virtuelle" Exception aus, im Exceptionhandler der dann durch das OS aufgerufen wird kannste nun die eigentliche Adresse der Assert() dem OS zur�ckgeben und erneut ein stilles raise aufrufen. Das OS w�rde dann an der Adresse vom Assert() die Exception-Ausl�sung vermuten und den Delphi Debugger starten. D.h. im Delphi Debugger w�rde erscheinen das an dieser stelle eine Exception aufgtreten ist, er w�rde aber mit F8,F9,F7 an dieser Stelle mit der Ausf�hrung des Programmes fortfahren. 

So was �hnliches habe ich mal als Anti-Debugging Trick benutzt. Im Grunde wird �ber das SEH = Structured Exception handling des OS der Ausf�hrungspfad der Anwendung so ver�ndert das ein bestimmerter Code ZWEIMAL hintereinander ausgef�hrt wird und denoch ein anderes Exceptionhandling benutzt wird. 

Gru� Hage

**Hagen Reddmann** · 06.06.2003, 11:50

Ah nochwas propier mal das, statt asm INT3 end;
Im Stack steht

<pre>

saved ESP
return address von CALL AssertProc
return addresse vom Assert 

Wir manipuliern nun so das dort steht 

saved ESP
return address von CALL AsserProc
return address vom assert
return adresss to INT3 

asm
POP EBP
MOV ESP,EBP
POP EAX
POP EDX
PUSH OFFSET @@1
PUSH EDX
PUSH EAX
RET

@@1: INT 3
RET
end; 

Normalerweise haben wir im Aufrufstack 

- call AssertErrorProc
- Assert() 

wir machen daraus nun: 

- call AssertErrorProc
- Assert()
- call @@1 = INT3 

wir jubeln also dem Aufrufstack unsere INT3 procedures so unter als w�re sie als erstes aufgerufen wurden. 
(topdown)

</pre>

Naja, nat�rlich ist das alles ungetestet und ganz WICHTIG dabei ist es zu wissen ob z.b. Assert() selber noch Daten im Stack liegen hat. Es mu� also noch experimentell gestestet werden damit wie nicht den Stack zerst�ren. 
Aber generell ist es dadurch m�glich das nach dem INT3 ein RET steht das direkt an die Adresse NACH dem Assert() zur�ckspringt. 

Gru� Hage

**Ulrich Gerhardt** · 06.06.2003, 17:10

Hoppla.
Mit den letzten 2,5 Postings hast du mich �berfordert. :-)
 Was meinst du mit "virtueller Exception" und "stillem raise"?
Sowas wie in SysUtils.RaiseAssertException? Das dortige Vorgehen
zerst�rt mir leider die lokalen Variablen im Umfeld des Assert.
Das w�rde ich gerne vermeiden, falls m�glich.
 Den asm-Block hab ich auch mal eingebaut, bin aber immer
wieder bzgl. einer "privilegierten Anweisung" ermahnt worden.
Ich hab ein bisschen mit der Reihenfolge der Anweisungen experimentiert
(irgendwie erschien mir die Reihenfolge der PUSHs und POPs unsymmetrisch :-)),
gelegentlich hat der Debugger dann sogar bei dem einen oder anderen RET angehalten,
die Ermahnung kam aber immer. Allerdings bin ich auch intuitiv und
v�llig wissensfrei vorgegangen.
Ciao, Uli.
PS: Nochmal Danke f�r deine Zeit. Ich bin ja immer wieder platt,
was f�r eine Unmenge von Infos du unter uns Halbwissenden verteilst.
(Ich will ja nicht von Perlen und S�uen sprechen... :-)

**Hagen Reddmann** · 06.06.2003, 18:54

Ok, heute abend setze ich mich mal ran. Das mit der Modifizierung des Callerstacks m�sste eigentlich funktionieren. Nur eben das man sowas life testen mu� da der Callerstack je nach �bergeordnetem Code sich �ndern kann. 
Im nachhinein w�rde ich sowieso lieber eine eigene Assemblerprocedure code da man dadurch geordnete Verh�ltnisse schafft. 

Das mit dem Exceptionhandler ist ein bi�chen anders. Ich rede hier nicht von dem offensichtlichen Exceptionframe den man in SysUtils.pas o.�. vorfindet. Normalerweise besteht ein Exceptionhandler aus folgendem
<pre>

@@1: try
@@2:
@@3: except
@@4: end;

</pre>

@@1 richtet inline des SEH ein, @@3 ist unser Code der ausgef�hrt wird wenn eine Exception ausgel�sst wurde, zwischen @@1 und @@2. @@4 ist die finalization des SEH. Nun, wenn eine Exception auftritt wird der unsichtbare Code an @@2 aufgerufen, da diese Adresse in @@1 eingerichtet wurde. Der Compiler legt dort Code an der in die RTL springt und diese arbeitet abh�nig vom Typ die Exception ab. Jenachdem teilt dieser RTL Code dem OS mit was passieren soll und gibt als R�cksrungadresse @@3 an. Nun, dieses St�ckchen Code von @@2 bis RTL wird durch das OS wie eine Callbackfunktion behandelt und l�uft auf Ring 0, d.h. h�chster Priviligierungsstufe, so hoch wie VXD/SYS Treiber. Dies ist auch der Grund warum Exceptions so langsam sind, da zwischen den Priveligierungen gewechselt wird. 

Statt nun einen normalen Delphi SEH einzurichten w�rden wir einen �hnlichen aber NICHT gleichen SEH per assembler einrichten. Statt @@3 als R�cksprungadresse w�rden wir eine ganz andere Adresse benutzen. Im Grunde ist es damit m�glich an einer beliebigen Adresse im Program die Ausf�hrung mit freiw�hlbaren Registern weiterlaufen zu lassen

Gru� Hage

**Hagen Reddmann** · 07.06.2003, 02:26

<pre>

<code>procedure ChoiceAssertErrorHandler(const Message, Filename: string; LineNumber: Integer; ErrorAddr: Pointer);
var
Behaviour: TAssertionBehaviour;
begin
Addr := ErrorAddr;
 
if AssertionBehaviour = abUserChoice then
Behaviour := GetUserChoice(Message, Filename, LineNumber, ErrorAddr)
else
Behaviour := AssertionBehaviour;
case Behaviour of
abHalt: FatalExit(666);
abDebug:
asm
JMP @@2
@@1: INT 3
RET
@@2: MOV EAX,OFFSET @@1
MOV [EBP + 4],EAX
end;
abDelphi:
OldAssertErrorProc(Message, Filename, LineNumber, ErrorAddr);
else //abIgnore:
// nix
end;
end;

</code></pre>

Damit kommste eine Ebene n�her ran. 
Ich habe es zwar auch schon geschafft das der Debugger hinter der Assert() stehen bleibt, aber nur weil ich die Debugregister Dr0-Dr7 als Breakpoints benutzt habe. Leider reagiert der Debugger in D5 nicht korrekt darauf. 
Die einzigste, saubere M�glichkeit, sehe ich nun darin durch ein Interface, sprich BPL mit Interprocesskommunikation, auf die Delphi IDE aus dem Program heraus zuzugreifen. Diese Schnittstelle sollte dann einen Breakpoint IN der IDE an der entsprechenden Stelle setzen. Normalerweise m�sste man irgendwie dieses auch direkt dem Debugger mitteilen, Delphi macht dies ja auch. 

Gru� hage

Announcement

DebugBreak und Delphi

DebugBreak und Delphi

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment