Manuelles Debuggen

Übersicht

BlitzMax, BlitzMax NG

FAQs und Tutorials

	klepto2 Betreff: Manuelles Debuggen	Do, Sep 21, 2006 10:31 Antworten mit Zitat
Tutorial für manuelles debuggen einer Blitzmax exe -------------------------------------------------- In diesem Tutorial wird beschrieben, wie man seine, mit Blitzmax erstellten Programme, manuel ohne IDE debuggen kann. So, dann fangen wir mal an: Wofür sollte manuelles debuggen gut sein? Es gibt hin und wieder Fehler im BMax Debugger, bei dem die IDE abstürzt oder einfach nicht alle relevanten Daten angezeigt werden. Außerdem könnte man dieses Wissen einsetzen um einen eigenen Debugger zuschreiben. Ein weiterer Grund könnte ein Support grund sein. Zum Beispiel funktioniert bei einem Kunden das Programm einfach nicht. Nun schickt man ihm eine bestimmte Version mit diesem debugger und kann nun direkt auf dem PC des Kunden den Fehler suchen. So, dann fangen wir mal an: Als erstes brauchen wir mal einen BeispielSource: Code: [AUSKLAPPEN] [EINKLAPPEN] Type TTest Field A:Int Method Multi() Print A * A End Method End Type Global Test:String = "Hello World" Out(Test) Local T:TTest = New TTest T.A = 16 T.Multi() Function Out(Output:String) DebugStop() Print Output End Function So, nix besonderes. Halt nur ein kleiner Test. Aber wie können wir nun manuell debuggen ? 1. Wir müssen "Debug Build" in der IDE angeschaltet haben. 2. wir müssen "Build Gui App" abgeschaltet haben. als nächstes compilieren wir unseren Source nur über den Build button und starten sie ausserhalb der IDE. Als nächstes erhalten wir ein Fenster mit folgendem Inhalt: Code: [AUSKLAPPEN] [EINKLAPPEN] ~>DebugStop: ~> so, nun kommt das was sonst eigentlich die BMax IDE intern macht. Um uns eine kleine Hilfe zu geben hat MArk Sibly uns eine kleine Hilfe eingebaut, die man mit dem Buchstaben 'H' und einer bestätigung mit "Enter" erreicht. Nachdem man dieses getan hat, erscheint folgendes: Code: [AUSKLAPPEN] [EINKLAPPEN] ~>T - Stack trace ~>R - Run from here ~>S - Step through sourcecode ~>E - Step into function call ~>L - Leave function or local block ~>Q - Quit ~>H - This text ~>Dxxxxxxxx - Dump object at hex address xxxxxxxx ~> Fangen wir mit den einfachen Erklärungen an: H = Help Also den Text den ihr gerade gesehen habt. Q = Quit Beendet die Anwendung an dieser Stelle R = Continue Führt die Anwendung bis zum nächsten Halt(Debugstop) weiter. --------------------------------------------- Nun zu den komplizierteren Befehlen: Folgende sind im Prinzip mit ihren equivalenten der IDE identisch S - entspricht dem einfachen Step der IDE E - entspricht dem einfachen Stepin der IDE L - entspricht dem Stepout Die anderen beiden Befehle (Stack (t)race und (D)ump) werde normalerweise intern von der IDE aufgerufen und werden gleich näher erlaütert. ---------------------------------------------- Das waren die Grundlagen, doch bis jetzt haben wir noch nicht viel von unseren Debugdaten gesehen. Das werden wir jetzt mal ändern: Als erstes geben wir nun in der Konsole ein 'T' ein und bestätigen mit 'Enter'. Nun sollte in etwa folgende Ausgabe kommen: Code: [AUSKLAPPEN] [EINKLAPPEN] T ~>StackTrace{ ~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<12,1> ~>Function test ~>Global Test:String="Hello World" ~>Local T:TTest=Null ~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<20,2> ~>Function Out ~>Local Output:String="Hello World" ~>} ~> Was haben wir nun gemacht: Wir haben die aktuellen TraceDaten des Debuggers ausgelesen, doch was bedeuten diese eigentlich: als erstes schauen wir uns mal die Struktur der Daten an: ein Block von Daten wird immer in geschweifte Klammern eingegrenzt '{,}' das Stacktrace weist uns daraufhin, was wir gerade abgerufen haben (eigentlich nur für die interressant, die einen eigenen Debugger bauen wollen). Nun zu den eigenlichen Daten: mit @ werden immer die aktuellen Positionen und die verschiedenen Scopes des Debugstops oder dem Fehler angegeben, in diesem Fall wurde der Hauptstop in der Zeile 21 Reihe 1 der test.bmx gemacht, also hier ist der Debugger in unsere Funktion mit dem Debugstop hineingesprungen. Darunter sehen wir jetzt die Liste von Variablen, die bis dahin deklariert wurden. Hier: Global Test und Local T Danach folgt wieder eine mit @ angeführte Zeile, die den aktuellen Scope des Debugstops wiedergibt, in diesem Fall die Funktion Out (beim ersten wird als Scope der name der aktuellen bmx datei als scope angegeben). Dann kommen die zu diesem Scope gehörigen Variablen (Local output) und der Datenblock wird dann mit einer } abgeschlossen. Doch was ist eigentlich dieser Dump Befehl? Um das zu erklären müssen wir mit unserem Beispiel nun ein paar sprünge machen, also solange abwechselnd 'S' + Enter und 'T' + Enter eingeben, bis folgende Ausgabe kommt: Code: [AUSKLAPPEN] [EINKLAPPEN] T ~>StackTrace{ ~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<15,1> ~>Function test ~>Global Test:String="Hello World" ~>Local T:TTest=$013b44d0 ~>} ~> Das meiste wurde ja schon erklärt. Wir befinden uns nun nur im Main scope der Datei test.bmx an Zeile 15 Reihe 1. Der Globalen Variable wurde schon ein Wert zugeordnet, doch was soll diese komische Hexzahl hinter der Local T:TTest? Also kurz gesagt, diese Hexaddresse beschreibt die Addresse, in der die Daten für diese Variable abgelegt sind. Um an diese Daten ranzukommen macht man nun folgendes: man gibt nun D013b44d0 (wobei die Addresse von der hier abweichen kann) ein und bestätigt wieder mit Enter. Nun kommt folgende Ausgabe: Code: [AUSKLAPPEN] [EINKLAPPEN] D013b44d0 ~>ObjectDump@013b44d0{ ~>Type TTest ~>Field A:Int=0 ~>} ~> in der ersten Zeile wird wieder gezeigt, das wir nun ein Objectdump an der addresse 013b44d0 ausgeführt haben. Die nächste Zeile sagt uns von welchen Type dieses Objekt ist (hier TTest). Dannach werden die Fields aufgelistet: Field A:Int = 0 und am Ende wieder mit einer } abgeschlossen. So, das wären die Grundlagen. Hier noch ein paar Tips: Beim Objectdump können die angeführten 0 weggelassen werden. Aufpassen das die exe auch wirklich regulär oder durch Quit beendet wird (ansonsten kann es passieren, das der Speicher (bei Windows) in Sekundenschnelle voll gemüllt wird. Dann viel Spaß beim ausprobieren Klepto2 Anregungen und Verbesserungen sind herzlich willkommen (gerade weil es mein erstes Tutorial ist und ich nicht wirklich der beste Screiber bin )
Matrix Screensaver Console Modul für BlitzMax KLPacker Modul für BlitzMax HomePage : http://www.brsoftware.de.vu

klepto2

Betreff: Manuelles Debuggen

Do, Sep 21, 2006 10:31
Antworten mit Zitat

Tutorial für manuelles debuggen einer Blitzmax exe
--------------------------------------------------

In diesem Tutorial wird beschrieben, wie man seine,
mit Blitzmax erstellten Programme, manuel ohne IDE
debuggen kann.

So, dann fangen wir mal an:

Wofür sollte manuelles debuggen gut sein?

Es gibt hin und wieder Fehler im BMax Debugger,
bei dem die IDE abstürzt oder einfach nicht alle
relevanten Daten angezeigt werden. Außerdem könnte man
dieses Wissen einsetzen um einen eigenen Debugger
zuschreiben. Ein weiterer Grund könnte ein Support
grund sein. Zum Beispiel funktioniert bei einem Kunden
das Programm einfach nicht. Nun schickt man ihm eine
bestimmte Version mit diesem debugger und kann nun direkt
auf dem PC des Kunden den Fehler suchen.

So, dann fangen wir mal an:

Als erstes brauchen wir mal einen BeispielSource:

Code: [AUSKLAPPEN]

Type TTest
Field A:Int

Method Multi()
Print A * A
End Method

End Type

Global Test:String = "Hello World"

Out(Test)

Local T:TTest = New TTest
T.A = 16
T.Multi()

Function Out(Output:String)
DebugStop()
Print Output
End Function

So, nix besonderes. Halt nur ein kleiner Test.
Aber wie können wir nun manuell debuggen ?

1. Wir müssen "Debug Build" in der IDE angeschaltet haben.
2. wir müssen "Build Gui App" abgeschaltet haben.

als nächstes compilieren wir unseren Source nur über den Build button
und starten sie ausserhalb der IDE.

Als nächstes erhalten wir ein Fenster mit folgendem Inhalt:

Code: [AUSKLAPPEN]

~>DebugStop:
~>

so, nun kommt das was sonst eigentlich die BMax IDE intern macht. Um uns
eine kleine Hilfe zu geben hat MArk Sibly uns eine kleine Hilfe eingebaut,
die man mit dem Buchstaben 'H' und einer bestätigung mit "Enter" erreicht.
Nachdem man dieses getan hat, erscheint folgendes:
Code: [AUSKLAPPEN]

~>T - Stack trace
~>R - Run from here
~>S - Step through sourcecode
~>E - Step into function call
~>L - Leave function or local block
~>Q - Quit
~>H - This text
~>Dxxxxxxxx - Dump object at hex address xxxxxxxx
~>

Fangen wir mit den einfachen Erklärungen an:

H = Help

Also den Text den ihr gerade gesehen habt.

Q = Quit

Beendet die Anwendung an dieser Stelle

R = Continue

Führt die Anwendung bis zum nächsten Halt(Debugstop) weiter.

---------------------------------------------

Nun zu den komplizierteren Befehlen:

Folgende sind im Prinzip mit ihren equivalenten der IDE identisch

S - entspricht dem einfachen Step der IDE
E - entspricht dem einfachen Stepin der IDE
L - entspricht dem Stepout

Die anderen beiden Befehle (Stack (t)race und (D)ump)
werde normalerweise intern von der IDE aufgerufen und werden gleich näher erlaütert.

----------------------------------------------

Das waren die Grundlagen, doch bis jetzt haben wir noch nicht viel von unseren Debugdaten gesehen.
Das werden wir jetzt mal ändern:

Als erstes geben wir nun in der Konsole ein 'T' ein und bestätigen mit 'Enter'.
Nun sollte in etwa folgende Ausgabe kommen:

Code: [AUSKLAPPEN]

T
~>StackTrace{
~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<12,1>
~>Function test
~>Global Test:String="Hello World"
~>Local T:TTest=Null
~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<20,2>
~>Function Out
~>Local Output:String="Hello World"
~>}
~>

Was haben wir nun gemacht:
Wir haben die aktuellen TraceDaten des Debuggers ausgelesen,
doch was bedeuten diese eigentlich:

als erstes schauen wir uns mal die Struktur der Daten an:

ein Block von Daten wird immer in geschweifte Klammern eingegrenzt '{,}'
das Stacktrace weist uns daraufhin, was wir gerade abgerufen haben (eigentlich
nur für die interressant, die einen eigenen Debugger bauen wollen).
Nun zu den eigenlichen Daten:

mit @ werden immer die aktuellen Positionen und die verschiedenen
Scopes des Debugstops oder dem Fehler angegeben, in diesem Fall wurde der
Hauptstop in der Zeile 21 Reihe 1 der test.bmx gemacht, also hier ist der
Debugger in unsere Funktion mit dem Debugstop hineingesprungen.
Darunter sehen wir jetzt die Liste von Variablen, die bis dahin
deklariert wurden.

Hier:
Global Test
und
Local T

Danach folgt wieder eine mit @ angeführte Zeile, die den aktuellen
Scope des Debugstops wiedergibt, in diesem Fall die Funktion Out
(beim ersten wird als Scope der name der aktuellen bmx datei als scope angegeben).

Dann kommen die zu diesem Scope gehörigen Variablen (Local output)

und der Datenblock wird dann mit einer } abgeschlossen.

Doch was ist eigentlich dieser Dump Befehl?
Um das zu erklären müssen wir mit unserem Beispiel nun ein paar sprünge machen,
also solange abwechselnd 'S' + Enter und 'T' + Enter eingeben, bis folgende Ausgabe
kommt:

Code: [AUSKLAPPEN]

T
~>StackTrace{
~>@D:/Dokumente und Einstellungen/Familie/Desktop/MiniB3D-v027/test.bmx<15,1>
~>Function test
~>Global Test:String="Hello World"
~>Local T:TTest=$013b44d0
~>}
~>

Das meiste wurde ja schon erklärt. Wir befinden uns nun nur im Main scope
der Datei test.bmx an Zeile 15 Reihe 1. Der Globalen Variable wurde schon
ein Wert zugeordnet, doch was soll diese komische Hexzahl hinter der Local T:TTest?
Also kurz gesagt, diese Hexaddresse beschreibt die Addresse, in der die
Daten für diese Variable abgelegt sind. Um an diese Daten ranzukommen
macht man nun folgendes:

man gibt nun D013b44d0 (wobei die Addresse von der hier abweichen kann)
ein und bestätigt wieder mit Enter.

Nun kommt folgende Ausgabe:

Code: [AUSKLAPPEN]

D013b44d0
~>ObjectDump@013b44d0{
~>Type TTest
~>Field A:Int=0
~>}
~>

in der ersten Zeile wird wieder gezeigt, das wir nun ein Objectdump
an der addresse 013b44d0 ausgeführt haben. Die nächste Zeile sagt uns
von welchen Type dieses Objekt ist (hier TTest).
Dannach werden die Fields aufgelistet:

Field A:Int = 0

und am Ende wieder mit einer } abgeschlossen.

So, das wären die Grundlagen. Hier noch ein paar Tips:

Beim Objectdump können die angeführten 0 weggelassen werden.
Aufpassen das die exe auch wirklich regulär oder durch Quit beendet wird
(ansonsten kann es passieren, das der Speicher (bei Windows) in Sekundenschnelle
voll gemüllt wird.

Dann viel Spaß beim ausprobieren Wink

Klepto2

Anregungen und Verbesserungen sind herzlich willkommen (gerade weil es mein erstes Tutorial ist und
ich nicht wirklich der beste Screiber bin Wink

)

Matrix Screensaver
Console Modul für BlitzMax
KLPacker Modul für BlitzMax

HomePage : http://www.brsoftware.de.vu

	hamZta Administrator	Do, Sep 21, 2006 18:40 Antworten mit Zitat
Dazu hab ich doch glatt eine Frage: Bei einigen "größeren" Spielen (zB WoW) tauchen oft Fehlermeldungen auf, die ganz genau beschreiben, wo der Fehler auftritt. Bei WoW steht der Name der Sourcedatei (*.cpp), der Funktionsname und die Zeilennummer. Ist das vll. irgendwie über den Debugger realisierbar? hamZta
Blog.

hamZta

Administrator

Do, Sep 21, 2006 18:40
Antworten mit Zitat

Dazu hab ich doch glatt eine Frage:
Bei einigen "größeren" Spielen (zB WoW) tauchen oft Fehlermeldungen auf, die ganz genau beschreiben, wo der Fehler auftritt. Bei WoW steht der Name der Sourcedatei (*.cpp), der Funktionsname und die Zeilennummer.

Ist das vll. irgendwie über den Debugger realisierbar?

hamZta

Blog.