[X] Debuggen mit Visual C++ 6

Shade Of Mine

estartu_de schrieb:

Da ich mit reinem C++ sehr auf Kriegsfuß stehe, würde ich den Teil mit dem Trace-Eigenbau gerne an jemanden mit Ahnung abgeben.

kein problem. war ja nur ne anregung

Meinst du mit "Profil" das normale vom Forum oder das im Autorenforum?

das autoren forum, deshalb ist es da. dort kommen nur profile rein.
die forum-profile haben mit dem magazin nichts zu tun.

Wenn es das im Forum ist, hätte ich eine Idee:
Wie wäre es, wenn nur der Autor selber auf seine Vorstellung anworten kann (oder meinetwegen die nur editieren)?
Denn was es über mein Leben zu diskutieren gibt weiß ich nicht wirklich.

ja, nichts zu diskutieren. editieren kann dann nur ich und der autor selber. beiträge schreiben ist verboten.

schließlich ist es eine Art eigene Visitenkarte.

das ist der gedanke dahinter. man soll sagen können "schau mal hier hin, da siehst was für tolle sachen ich schon gemacht habe"

Oder wie ist das Autorenforum gedacht? Ich blicke da noch nicht durch.

ja exakt so: nur profile der autoren. (und uU der anderen mitarbeiter auch, wenn diese unbedingt wollen, da lässt sich reden)

estartu

Shade Of Mine schrieb:

Wenn es das im Forum ist, hätte ich eine Idee:
Wie wäre es, wenn nur der Autor selber auf seine Vorstellung anworten kann (oder meinetwegen die nur editieren)?
Denn was es über mein Leben zu diskutieren gibt weiß ich nicht wirklich.

ja, nichts zu diskutieren. editieren kann dann nur ich und der autor selber. beiträge schreiben ist verboten.

Wie kommt dann mein Profil da rein?
Schreib ich das hier und du schiebst?

Shade Of Mine

estartu_de schrieb:

Wie kommt dann mein Profil da rein?
Schreib ich das hier und du schiebst?

ich hab leider keinen zugriff auf die rechte vergabe. aber theoretisch müsste jedes magazin mitglied einen thread erstellen dürfen. ich schliesse ihn nachher einfach und gut ist

estartu

Okay, so ist es schön einfach.
Du solltest das aber nochmal als Extrathread erklären - hier guckt doch keiner zu dem Thema rein.

estartu

So, ich werde morgen früh nochmal drüberlesen, aber ich denke, ich bin fertig.

Ich habe zu allem etwas geschrieben und bräuchte jetzt einen Neuling, der mal guckt ob man mit der Anleitung auch etwas anfangen kann, und einen Profi, der kontrolliert, ob ich keine Fehler drin habe.

Kann ich davon ausgehen, dass das veröffentlicht wird und mich schon mal auf mein Profil stürzen?

An die Rechtschreib-Korrektur-Leser:
Da irgendwann, während ich dran geschrieben habe, festgelegt wurde, dass man als Anrede "Sie" verwenden soll, kann es bunt gemischt sein - achtet da bitte etwas drauf.
Auch hatte ich früher in der Schule immer das Problem, in den Zeiten zu springen oder auch Bandwurmsätze zu produzieren. Ich selber sehe die Fehler nicht.

Danke schonmal

Mr. B

Mit welchen tags soll ich jetz die fehler markieren?

Bin Neuling - könnte also auch probieren, ob ich damit was anfangen könnte.

Mr. B

estartu

Da ich [ u ] nicht verwendet habe nimm von mir aus bitte das.

Mr. B

estartu_de schrieb:

Worum geht's hier?
Über Programmieren im Sinne von "Quellcode erstellen" gibt es unzählige Bücher.
Über das Finden und Beheben von Fehlern leider nicht, obwohl es genauso wichtig ist und auch einen großen Anteil am Arbeitsleben eines Softwareentwicklers hat.
Denn auch nach mehreren Jahren als Softwareentwickler ist das Debuggen von Anwendungen eine tägliche Aufgabe, da man wohl nie auf Anhieb fehlerfreien Code produziert.
Im Laufe der Jahre eignet man sich als debuggender Entwickler viele Tricks und Kniffe an, die auch Anfänger zu Beginn ihrer "Laufbahn" schon gut gebrauchen könnten.
In diesem Artikel erfahren Sie von mir die ersten Grundlagen und ich werde Ihnen den oftmals steinigen Weg des Debuggens zeigen.

Ich möchte in diesem Artikel alles zusammentragen, was mir bisher zum Debuggen bekannt ist.
Angefangen bei den Grundlagen bis hin zu häufigen Fehlern, die sich im Debugger erkennen lassen, und auch Techniken, mit denen man sich die Fehlersuche erleichtern kann.
Aber auch auf "Macken und Eigenheiten" des Debuggers werde ich eingehen.

Dieser Artikel bezieht sich auf Visual C++ 6 (SP6). Sie sollten aber eigentlich alles ohne Probleme auch in den Nachfolgerversionen finden können.
Natürlich haben auch andere Entwicklungsumgebungen (auch von anderen Programmiersprachen) einen Debugger und vieles von hier wird man übertragen können.

Englisch ist die Sprache aller Softwareentwickler, daher verwende ich überwiegend die englischen Fachausdrücke in diesem Artikel. Soweit möglich ergänze ich diese auch um die deutsche Übersetzung.
__________________________________________________________________________________________________

Was ist der Debugger?
Der Debugger ist ein Teil von VC, der Ihnen hilft, Fehler zu finden.
Sie können dem Programm direkt "bei der Arbeit" zuschauen.
Da so ein Programm aber schnell sehr komplex wird, gibt es unzählige Hilfsmittel.
__________________________________________________________________________________________________

Haltepunkte / Breakpoints
Ein Breakpoint ist eine Marke (roter Punkt), wo das Programm in der Ausführung unterbrochen wird, wenn die so markierte Anweisung an der Reihe ist.

Man kann Breakpoints mit F9 setzen und auch wieder entfernen.
Außerdem gibt es einen Dialog zum Verwalten aller Breakpoints; man erhält ihn über

Strg + B

Alt + F9

Menü "Bearbeiten" -> "Haltepunkte..."

Zusätzlich gibt es noch die Symbolleiste "Debug", die man über "Anpassen" noch um viele nützliche Schaltflächen erweitern kann (und sollte).
Da die Symbolleistenbefehle auch im Menü zu finden sind, werde ich sie ab jetzt nicht mehr erwähnen.

Breakpoints funktionieren nur, wenn das Programm auch im Debugmodus gestartet wurde. Das geht mit

F5

Menü "Erstellen" - "Debug starten" -> "Ausführen"

Es gibt noch die Möglichkeit, den Debug mit F10 oder F11 zu starten, das bietet sich bei komplexen Programmen aber nicht an.

Man kann einzelne Breakpoints auch nur unter einer Bedingung aktivieren.
Das ist in dem Fall nützlich, wenn man sich beispielsweise eine for-Schleife erst ab dem 1000. Durchlauf ansehen möchte.
Die Bedingung kann man in dem o.g. Dialog festlegen.
Hier kann man auch angeben, beim wievielten Mal "am Breakpoint vorbeikommen" das Programm erst angehalten werden soll.
__________________________________________________________________________________________________

Bewegungsmöglichkeiten in der Ausführung
Da Sie ja sicherlich nicht nur den Zustand des Programms zu dem Zeitpunkt, wo der Breakpoint sitzt, beobachten wollen, können Sie auch schrittweise weitermachen.

Das geht mit

F10: Eine Anweisung weiter

F11: In die Funktion springen

und weiteren Befehlen im Menü "Debug"

Welcher dieser Befehle angebracht ist, hängt von der jeweiligen Situation ab.
Meistens werden Sie F10 nutzen, aber wenn Sie sehen möchten, was in einer Funktion mit ihren Variablen gemacht wird, dann brauchen Sie F11 und unter Umständen viel Geduld, denn für jeden Parameter laufen Sie erst einmal durch den passenden Konstruktor (KOMMA???) bevor Sie in der Funktion landen, die Sie ansehen wollten.

Dafür hat dies aber den Vorteil, dass Sie nach und nach sehr viel über die innere Funktionsweise der MFC lernen, und je öfter Sie sich in die "Innereien" vorwagen, desto sicherer werden Sie Sich bewegen können.
__________________________________________________________________________________________________

Aufrufliste / Callstack
Der Callstack ist ein Unterfenster vom VC, in dem bei angehaltener Programmausführung gezeigt wird, welche Funktion welche mit was für Parametern aufgerufen hat, bis man da gelandet ist, wo man gerade "steht".
Die aufgerufene Funktion steht immer über der aufrufenden.
CAd3App::InitInstance() line 124
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e98989()
Den Callstack kann man einblenden, indem man im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufruft und dort das Häkchen bei "Aufrufliste" setzt

im Menü "Ansicht" - "Debug-Fenster" -> "Aufrufliste" wählt

Alt + 7 drückt.

Nicht alle Zeilen im Callstack sind normal lesbar. Bei einigen steht da etwas wie
KERNEL32! 77e98989()
Dort können Sie auch drauf doppelklicken, aber Sie werden nur Assemblercode zu sehen bekommen. Für diese Funktionen gibt es keinen Quellcode.

Der kleine grüne Pfeil am linken Rand im Editor zeigt, welcher Befehl gerade an der Reihe ist. Allerdings ist er nur dann auf dem aktuellen Befehl, wenn Sie in der allerobersten Funktion stehen.
Wenn man per Doppelklick auf die gewünschte Zeile im Callstack in eine andere Funktion wechselt, dann zeigt er immer auf die Zeile, die als nächstes ausgeführt werden soll.
__________________________________________________________________________________________________

Gültigkeitsannahmen (ASSERT)
ASSERTs dienen zu Prüfung, ob für die Programmausführung nötige Werte eingehalten werden.
Ein ASSERT löst dann eine Meldung aus, wenn die Bedingung in den Klammern nicht erfüllt ist. Will man z.B. immer benachrichtigt werden, schreibt man
ASSERT(FALSE);
wogegen
ASSERT(TRUE);
ziemlich sinnlos ist.

Man sollte so beispielsweise Zeiger grundsätzlich prüfen:
int* pInt = NULL;
ASSERT(pInt); // für Schreibfaule
ASSERT(pInt != NULL); // für Perfektionisten
Dieser Code würde eine Assertion produzieren, die von Anfängern auch gerne als Fehlermeldung bezeichnet wird. Bei der Meldung hat man aber die Möglichkeit, "Wiederholen"/"Retry" zu drücken und wird genau auf der Zeile mit dem ASSERT landen, der die Meldung ausgelöst hat.
Damit solche Prüfungen möglich sind, muss man aber sorgfältig arbeiten, denn das hier würde keine Assertion auslösen:
int* pInt; // Initialisierung vergessen
ASSERT(pInt);
So ist der ASSERT eine gute Möglichkeit, sich um Fehler zu kümmern bevor das Programm abstürzt.
Man lässt sich einfach durch ASSERTs melden, wenn das Programm wegen eines fehlerhaften Variableninhalts nicht mehr fehlerfrei ausgeführt werden kann.
Tritt dieser Zustand ein, wird man als Entwickler darauf hingewiesen und kann sich das Problem "am lebenden Objekt" ansehen.

ASSERT ist ein Befehl, der nur in der Debugversion funktioniert.
Daher darf man in den Klammern nichts schreiben, was für die Releaseversion wichtig ist.
Also macht bitte niemals sowas:
ASSERT(SpeichereMeineDaten(CFile* f_datei));
Dazu lesen Sie aber am besten auch Surviving the Release Version bei Codeproject.
__________________________________________________________________________________________________

Der ASSERT steht in MFC Quellcodes, was nun?
Sie haben auf "Wiederholen" gedrückt und stehen nun mitten im fremden Quellcode?
Dann gehen Sie doch im Callstack in die oberste Funktion, die von Ihnen ist und schauen Sie dort mal nach dem Rechten.
Dort scheint alles okay? Hangeln Sie sich immer weiter in die jeweils aufrufende Funktion, denn irgendwo ist der Fehler schon versteckt.

So ein ASSERT hat in der MFC entweder einen Kommentar oder er lässt sich fast wie im Klartext lesen. Ein
ASSERT(IsWindow(...));
zeigt Ihnen, dass Sie nach irgendwas suchen müssen, was mit einem Zugriff auf ein Fenster zu tun hat.
__________________________________________________________________________________________________

Geprüfte Befehle (VERIFY)
Sie können sich auch benachrichtigen lassen, falls eine Funktion einen bestimmten Wert zurückgibt.
Sicher könnten Sie das auch mit ASSERT machen, aber das gäbe ja Probleme in der Release-Version.

Gegenüber dem o.g. Beispiel ist es aber vollkommen okay
VERIFY(SpeichereMeineDaten(CFile* f_datei));
zu schreiben.
__________________________________________________________________________________________________

Die Debugausgabe
Wer noch unter DOS programmieren gelernt hat, wird es noch kennen, dass man im Zweifelsfall kleine Ausgaben gemacht hat, um zu sehen, ob das Programm auch hinter den Kulissen tut, was es soll.
Das geht z.B. bei einer SDI ja gar nicht mehr so einfach und außerdem hat sich Microsoft etwas praktisches einfallen lassen, was die Hilfsausgaben von den eigentlichen Ausgaben trennt: Die Debugausgabe.

Die Debugausgabe kann man einblenden, indem man

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufruft und dort das Häkchen bei "Ausgabe" setzt

im Menü "Ansicht" - "Ausgabe" wählt

Alt + 2 drückt.

Dort gibt die MFC schon automatisch Informationen aus und Sie können das auch.
__________________________________________________________________________________________________

Hilfsausgaben (TRACE)
Mit TRACE kann man sich beliebige Daten in der Debugausgabe ausgeben lassen.
Es erinnert in der Nutzung an printf bzw. CString::Format und ist deswegen sehr einfach zu handhaben.

Wenn Sie sehen möchten, welchen Inhalt ihre Variablen haben, können Sie das ganz einfach ausgeben lassen:
int nZahl = 10;
CString strText = "Die Zahl ist";
TRACE("%s: %d\n", strText, nZahl);
Man sollte das "\n" nicht vergessen, sonst hat man einen langen Text in der Ausgabe.

Das eingebaute TRACE ist soweit ja sehr schön, es gibt aber ein paar Gründe, ein eigenes zu schreiben, was das Original nutzt, aber etwas mehr kann.

TRACE kann keine BOOL oder bool.

TRACE kann kein Datum.

Will man nachträglich noch in eine Datei tracen, ist es weniger Arbeit.

Man kann sich alles Mögliche einfallen lassen, was einem das Leben erleichtert.

__________________________________________________________________________________________________

Lokale Überwachung
In der lokalen Überwachung finden Sie alle im aktuellen Zusammenhang bekannten Variablen und, wenn Sie sich mit F10 bewegen, auch die Rückgabewerte von gerade ausgeführten Funktionen.
Hat sich ein Wert eben gerade geändert, wird er rot dargestellt.

Die Überwachung kann man einblenden, indem man im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufruft und dort das Häkchen bei "Überwachung" setzt

im Menü "Ansicht" - "Debug-Fenster" -> "Überwachung" wählt

Alt + 3 drückt.

__________________________________________________________________________________________________

Variableninhalte überwachen
In der Überwachung können Sie sich alle Variablen zusammensammeln, die Sie beobachten möchten.
Ist eine Variable nicht gültig, wird dies angezeigt, sonst ihr Inhalt.
Sie sparen sich so die ständige Suche, wo denn welche Variable gerade in der lokalen Überwachung steht.
Außerdem können Sie auch direkt nur Membervariablen von Klassen beobachten und müssen nicht ständig die Klasse aufklappen.

Die Überwachung kann man einblenden, indem man im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufruft und dort das Häkchen bei "Variablen" setzt

im Menü "Ansicht" - "Debug-Fenster" -> "Variablen" wählt

Alt + 4 drückt.

__________________________________________________________________________________________________

Sonderfälle beim Debuggen
Sobald Sie die Anzeige Ihres Programms debuggen wollen, werden Sie schnell ein Problem haben.
Ein Breakpoint in OnPaint mutiert zu einer "Endlosschleife". Einer in OnUpdateCommandUI-Funktionen ebenfalls und OnCtlColor ist ebenfalls ein Problemfall. (Ich würde Sätze formulieren oder wenigstens eine Aufzählung in einem Satz. Die Wiederholung von "ebenfalls" hört sich extrem schaurig an...)
Dies sind drei Beispiele, denen man häufiger begegnet.

Um diese zu debuggen, muss man sein Programm und das VC so auf dem Bildschirm platzieren, dass sie sich nicht überschneiden. Wer eine Mehrschirmlösung hat ist hier klar im Vorteil, besonders bei großen Fenstern.

Der Grund dafür ist übrigens sehr einfach:
Nehmen wir an, Sie haben einen Breakpoint in OnPaint.
OnPaint wird immer aufgerufen, wenn das Fenster neu angezeigt werden muss. Es passiert nun folgendes:
1.) Das Programm startet
2.) Das Fenster wird angezeigt
3.) Man läuft auf den Breakpoint auf
4.) Man lässt das Programm mit F5 weiterlaufen
5.) GOTO 2.

OnUpdateCommandUI zu debuggen wird besonders bei Toolbarbuttons zur Qual, denn die werden ständig aktualisiert.
__________________________________________________________________________________________________

Endlosschleifen debuggen
Ihr Programm hängt und Sie haben keine Ahnung, warum?
Dann halten Sie es einfach an. Der Befehl dazu ist im Menü "Debug": "Anhalten"
__________________________________________________________________________________________________

Wenn Fehler beim Debug nicht mehr auftreten
Sie wollen einen Fehler suchen, aber immer wenn Sie ihm im Debugger auf die Schliche kommen wollen, ist er weg?
Dann ist es einer der schwierigeren Sorte.

Eine Möglichkeit ist, dass einfach ein Neuzeichnen des Fensters nötig ist.
Dann haben Sie irgendwo ein Invalidate vergessen. So einfach die Erklärung ist, man kann bei der Suche verzweifeln.

Eine andere Möglichkeit ist, dass der Fehler nur auftritt, wenn (???) das Programm mit normaler Geschwindigkeit läuft.
Da man beim Debuggen immer wieder anhält, wird man den wohl nie auf diese Weise finden. Dann sollte man zu TRACEs und evtl. bedingten Breakpoints greifen.
__________________________________________________________________________________________________

Ich habe einen Fehler in der MFC gefunden...
Oh, Sie haben echt was drauf - bewerben Sie Sich schnell bei Microsoft... äh nein, war ein Scherz.
Es klingt zwar überheblich, aber in der MFC sind keine Fehler. Davon können Sie einfach ausgehen und müssen dort nicht suchen.

Sollte es mal so scheinen, dann haben Sie verschiedene Möglichkeiten:

Lassen Sie erst einmal ein "Rebuild All" / "Alles neu erstellen" machen

Haben Sie schon den aktuellsten Service Pack für Ihr VC installiert? Nein? Dann holen Sie das nach.

Sollte das alles nicht helfen, haben Sie irgendwo einen Fehler in Ihrem Quellcode.
__________________________________________________________________________________________________

Der Debugger spinnt
Breakpoints, die Sie setzen, landen ein paar Zeilen höher oder tiefer?
Beim Debuggen werden Teile übersprungen, die eigentlich durchlaufen werden müssten, weil sie in keiner if oder Schleife stehen?
Dann nehmen Sie sich eine Tasse Kaffee und wählen im Menü "Erstellen" - "Alles neu erstellen" (Rebuild All).
Dieser Befehl sollte immer Ihre erste Wahl bei unerklärlichen Fehlern sein, denn leider ist Visual C++ nicht ganz fehlerfrei (oder wie man dieses Verhalten auch immer nennen will) und kommt manchmal durcheinander.

Sollte das nicht geholfen haben, können Sie bei VC6 noch die ncb und die opt Datei löschen (vorher schließen Sie bitte das Projekt).
Sollten Sie in der Klassenansicht mit Ordnern arbeiten, machen Sie vorher ein Backup, denn die Ordner sind dann weg.
__________________________________________________________________________________________________

Änderungen übernehmen und weiterdebuggen
Ihnen wird von Microsoft die Möglichkeit gegeben, während des Debuggens den Code zu ändern und danach mit den vorgenommenen Änderungen weiterzuarbeiten.
Auch Variableninhalte lassen sich ändern, das ist bei Schleifen manchmal praktisch, wenn man ein bestimmtes Verhalten provozieren will.
Das klingt zwar alles ganz toll - aber ich persönlich vertraue der Technik nicht und starte immer wieder von vorne.
__________________________________________________________________________________________________

Debuggen der Release-Version
Sie sind fertig, erstellen die Release-Version und... nichts geht mehr. In der Debug ist aber alles in Ordnung und den Artikel bei Codeproject haben Sie sich auch zu Herzen genommen?

Dann können Sie in den Projekteinstellungen die Debuginfos zuschalten und die Release-Version ganz normal debuggen.
Der feine Unterschied ist, dass jetzt aber _DEBUG nicht mehr definiert ist und die ganzen "Hilfestellungen" dadurch wegfallen. Falls Sie also unsauber programmiert haben, beispielsweise Zeiger nicht initialisiert haben, dann rächt sich das jetzt.

Für mehr Informationen lesen Sie bitte auch diesen Artikel.

Das Programm läuft bei Ihnen im Testbetrieb fehlerfrei, aber beim Kunden will es partout nicht laufen?
Tja, dort können Sie nicht mal eben ein Visual C++ installieren und gucken was los ist.
Bevor Sie nun per Remote-Debug auf Fehlersuche gehen, haben Sie noch eine Möglichkeit:
Sie bauen im Programm kleine Messageboxen ein, die Ihnen an wichtigen Stellen Informationen geben (für so eine Suche brauchen Sie aber einen Kunden mit guten Nerven), oder Sie lassen die Infos in eine Datei ausgeben.
Egal für was Sie sich an dieser Stelle entscheiden, es wäre sinnvoll gewesen, das schon von Anfang an vorzubereiten, indem Sie sich eigene Helferfunktionen (z.B. ein TRACE) geschrieben hätten, denn dann wäre eine Ausgabe in eine Datei nur ein geringer Aufwand.
__________________________________________________________________________________________________

Threads wechseln
Oft laufen (auch wenn Sie das gar nicht eingebaut haben) mehrere Threads parallel ab.
Hin und wieder landet man beim Unterbrechen im falschen und muss wechseln.
Das geht im Menü "Debug" - "Threads".
Doppelklicken Sie dort einfach auf den gewünschten und Sie werden an die aktuelle Position im Quellcode gebracht.
__________________________________________________________________________________________________

Bei Ausnahmen unterbrechen
Sie sehen in der Debug-Ausgabe dauernd Zeilen wie
Nicht abgefangene Ausnahme in ...
können aber nicht finden, wo der Fehler ist?
Dann können Sie im Menü "Debug" mit "Ausnahmen..." ein Dialogfeld aufrufen, wo Sie einstellen können, wie sich der Debugger bei welcher Ausnahme verhalten soll:

Immer anhalten

Anhalten, wenn sie nicht behandelt wurde

__________________________________________________________________________________________________

Das Debuggen beenden
Wenn Sie das Programm vorzeitig beenden wollen, etwa weil Sie ohne den Debugger den Code ändern möchten oder es auch einfach nicht mehr stabil laufen will, dann können Sie das mit "Debug beenden" im Menü Debug.
__________________________________________________________________________________________________

Was man noch gelesen haben sollte

jQT- Debuggen im Borland C++ Builder
Eine sehr schön erklärte und bebilderte Einführung, die man mit wenigen Anpassungen für Visual C++ übernehmen kann. (Danke @ junix)

Artikel zum Debuggen bei Codeproject
Codeproject ist wohl die Anlaufstelle für ratlose oder Ideen suchende Entwickler. Und natürlich haben sie auch etwas zum Thema Debuggen zu bieten.

Verwenden des Debuggers in der MSDN

Debuggen der Release-Version
Eine Erklärung mit einigen guten Links. Der Artikel ist auf jeden Fall lesenswert. (Danke @ Redhead)

Hui. Jetzt ist erst einmal Feierabend. Ein paar Tipps für dich:

- vor "indem" immer ein Komma.
- das Reflexivpronomen "sich" wird (außer am Satzanfang) IMMER kleingeschrieben

Besonders am Anfang gabs viele Wechsel der Perspektive. Das war teilweise so viel und ich hab das so spät gemerkt, dass du das selbst noch einmal durchschauen musst. Manchmal hab ichs verbessert. Trotzdem: Alles mit "man" und Passiv und "du" solltest du am besten in die Sie-Anrede umformen.

Mr. B

estartu

Worum geht's hier?
Über Programmieren im Sinne von "Quellcode erstellen" gibt es unzählige Bücher.
Über das Finden und Beheben von Fehlern leider nicht, obwohl es genauso wichtig ist und auch einen großen Anteil am Arbeitsleben eines Softwareentwicklers hat.
Denn auch nach mehreren Jahren als Softwareentwickler ist das Debuggen von Anwendungen eine tägliche Aufgabe, da man wohl nie auf Anhieb fehlerfreien Code produziert.
Im Laufe der Jahre eignet man sich als debuggender Entwickler viele Tricks und Kniffe an, die auch Anfänger zu Beginn ihrer "Laufbahn" schon gut gebrauchen könnten.
In diesem Artikel erfahren Sie von mir die ersten Grundlagen und ich werde Ihnen den oftmals steinigen Weg des Debuggens zeigen.

Ich möchte in diesem Artikel alles zusammentragen, was mir bisher zum Debuggen bekannt ist.
Angefangen bei den Grundlagen bis hin zu häufigen Fehlern, die sich im Debugger erkennen lassen, und auch Techniken, mit denen Sie sich die Fehlersuche erleichtern können.
Aber auch auf "Macken und Eigenheiten" des Debuggers werde ich eingehen.

Dieser Artikel bezieht sich auf Visual C++ 6 (SP6). Sie sollten aber eigentlich alles ohne Probleme auch in den Nachfolgerversionen finden können.
Natürlich haben auch andere Entwicklungsumgebungen (auch von anderen Programmiersprachen) einen Debugger und vieles von hier werden Sie übertragen können.

Englisch ist die Sprache aller Softwareentwickler, daher verwende ich überwiegend die englischen Fachausdrücke in diesem Artikel. Soweit möglich ergänze ich diese auch um die deutsche Übersetzung.
__________________________________________________________________________________________________

Was ist der Debugger?
Der Debugger ist ein Teil von VC, der Ihnen hilft, Fehler zu finden.
Sie können dem Programm direkt "bei der Arbeit" zuschauen.
Da so ein Programm aber schnell sehr komplex wird, gibt es unzählige Hilfsmittel.
__________________________________________________________________________________________________

Haltepunkte / Breakpoints
Ein Breakpoint ist eine Marke (roter Punkt), wo das Programm in der Ausführung unterbrochen wird, wenn die so markierte Anweisung an der Reihe ist.

Sie können Breakpoints mit F9 setzen und auch wieder entfernen.
Außerdem gibt es einen Dialog zum Verwalten aller Breakpoints; Sie erhalten ihn über

Strg + B
Alt + F9
Menü "Bearbeiten" -> "Haltepunkte..."

Zusätzlich gibt es noch die Symbolleiste "Debug", die Sie über "Anpassen" noch um viele nützliche Schaltflächen erweitern können (und sollten).
Da die Symbolleistenbefehle auch im Menü zu finden sind, werde ich sie ab jetzt nicht mehr erwähnen.

Breakpoints funktionieren nur, wenn das Programm auch im Debugmodus gestartet wurde. Das geht mit

F5
Menü "Erstellen" - "Debug starten" -> "Ausführen"

Es gibt noch die Möglichkeit, den Debug mit F10 oder F11 zu starten, das bietet sich bei komplexen Programmen aber nicht an.

Sie können einzelne Breakpoints auch nur unter einer Bedingung aktivieren.
Das ist in dem Fall nützlich, wenn Sie sich beispielsweise eine for-Schleife erst ab dem 1000. Durchlauf ansehen möchten.
Die Bedingung können Sie in dem o.g. Dialog festlegen.
Hier können Sie auch angeben, beim wievielten Mal "am Breakpoint vorbeikommen" das Programm erst angehalten werden soll.
__________________________________________________________________________________________________

Bewegungsmöglichkeiten in der Ausführung
Da Sie ja sicherlich nicht nur den Zustand des Programms zu dem Zeitpunkt, wo der Breakpoint sitzt, beobachten wollen, können Sie auch schrittweise weitermachen.

Das geht mit

F10: Eine Anweisung weiter
F11: In die Funktion springen
und weiteren Befehlen im Menü "Debug"

Welcher dieser Befehle angebracht ist, hängt von der jeweiligen Situation ab.
Meistens werden Sie F10 nutzen, aber wenn Sie sehen möchten, was in einer Funktion mit ihren Variablen gemacht wird, dann brauchen Sie F11 und unter Umständen viel Geduld, denn für jeden Parameter laufen Sie erst einmal durch den passenden Konstruktor, bevor Sie in der Funktion landen, die Sie ansehen wollten.

Dafür hat dies aber den Vorteil, dass Sie nach und nach sehr viel über die innere Funktionsweise der MFC lernen, und je öfter Sie sich in die "Innereien" vorwagen, desto sicherer werden Sie sich bewegen können.
__________________________________________________________________________________________________

Aufrufliste / Callstack
Der Callstack ist ein Unterfenster vom VC, in dem bei angehaltener Programmausführung gezeigt wird, welche Funktion welche mit was für Parametern aufgerufen hat, bis zu der Stelle, wo Sie gerade "stehen".
Die aufgerufene Funktion steht immer über der aufrufenden.

CAd3App::InitInstance() line 124
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e98989()

Den Callstack können Sie einblenden, indem Sie im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Aufrufliste" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Aufrufliste" wählen
Alt + 7 drücken.

Nicht alle Zeilen im Callstack sind normal lesbar. Bei einigen steht da etwas wie

KERNEL32! 77e98989()

Darauf können Sie auch doppelklicken, aber Sie werden nur Assemblercode zu sehen bekommen. Für diese Funktionen gibt es keinen Quellcode.

Der kleine grüne Pfeil am linken Rand im Editor zeigt, welcher Befehl gerade an der Reihe ist. Allerdings ist er nur dann auf dem aktuellen Befehl, wenn Sie in der allerobersten Funktion stehen.
Wenn Sie per Doppelklick auf die gewünschte Zeile im Callstack in eine andere Funktion wechseln, dann zeigt er immer auf die Zeile, die als nächstes ausgeführt werden soll.
__________________________________________________________________________________________________

Gültigkeitsannahmen (ASSERT)
ASSERTs dienen zu Prüfung, ob für die Programmausführung nötige Werte eingehalten werden.
Ein ASSERT löst dann eine Meldung aus, wenn die Bedingung in den Klammern nicht erfüllt ist. Wollen Sie z.B. immer benachrichtigt werden, schreiben Sie

ASSERT(FALSE);

wogegen

ASSERT(TRUE);

ziemlich sinnlos ist.

Sie sollten so beispielsweise Zeiger grundsätzlich prüfen:

int* pInt = NULL;
ASSERT(pInt); // für Schreibfaule
ASSERT(pInt != NULL); // für Perfektionisten

Dieser Code würde eine Assertion produzieren, die von Anfängern auch gerne als Fehlermeldung bezeichnet wird. Bei der Meldung haben Sie aber die Möglichkeit, "Wiederholen"/"Retry" zu drücken und werden genau auf der Zeile mit dem ASSERT landen, der die Meldung ausgelöst hat.
Damit solche Prüfungen möglich sind, müssen Sie aber sorgfältig arbeiten, denn das hier würde keine Assertion auslösen:

int* pInt; // Initialisierung vergessen
ASSERT(pInt);

So ist der ASSERT eine gute Möglichkeit, sich um Fehler zu kümmern bevor das Programm abstürzt.
Sie lassen sich einfach durch ASSERTs melden, wenn das Programm wegen eines fehlerhaften Variableninhalts nicht mehr fehlerfrei ausgeführt werden kann.
Tritt dieser Zustand ein, werden Sie als Entwickler darauf hingewiesen und können sich das Problem "am lebenden Objekt" ansehen.

ASSERT ist ein Befehl, der nur in der Debugversion funktioniert.
Daher dürfen Sie in den Klammern nichts schreiben, was für die Releaseversion wichtig ist.
Also machen Sie bitte niemals sowas:

ASSERT(SpeichereMeineDaten(CFile* f_datei));

Dazu lesen Sie aber am besten auch Surviving the Release Version bei Codeproject.
__________________________________________________________________________________________________

Der ASSERT steht in MFC Quellcodes, was nun?
Sie haben auf "Wiederholen" gedrückt und stehen nun mitten im fremden Quellcode?
Dann gehen Sie doch im Callstack in die oberste Funktion, die von Ihnen ist und schauen Sie dort mal nach dem Rechten.
Dort scheint alles okay? Hangeln Sie sich immer weiter in die jeweils aufrufende Funktion, denn irgendwo ist der Fehler schon versteckt.

So ein ASSERT hat in der MFC entweder einen Kommentar oder er lässt sich fast wie im Klartext lesen. Ein

ASSERT(IsWindow(...));

zeigt Ihnen, dass Sie nach irgendwas suchen müssen, was mit einem Zugriff auf ein Fenster zu tun hat.
__________________________________________________________________________________________________

Geprüfte Befehle (VERIFY)
Sie können sich auch benachrichtigen lassen, falls eine Funktion einen bestimmten Wert zurückgibt.
Sicher könnten Sie das auch mit ASSERT machen, aber das gäbe ja Probleme in der Release-Version.

Gegenüber dem o.g. Beispiel ist es aber vollkommen okay

VERIFY(SpeichereMeineDaten(CFile* f_datei));

zu schreiben.
__________________________________________________________________________________________________

Die Debugausgabe
Wenn Sie noch unter DOS programmieren gelernt haben, werden Sie es noch kennen, dass man im Zweifelsfall kleine Ausgaben gemacht hat, um zu sehen, ob das Programm auch hinter den Kulissen tut, was es soll.
Das geht z.B. bei einer SDI ja gar nicht mehr so einfach und außerdem hat sich Microsoft etwas praktisches einfallen lassen, was die Hilfsausgaben von den eigentlichen Ausgaben trennt: Die Debugausgabe.

Die Debugausgabe können Sie einblenden, indem Sie

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Ausgabe" setzen
im Menü "Ansicht" - "Ausgabe" wählen
Alt + 2 drücken.

Dort gibt die MFC schon automatisch Informationen aus und Sie können das auch.
__________________________________________________________________________________________________

Hilfsausgaben (TRACE)
Mit TRACE können Sie sich beliebige Daten in der Debugausgabe ausgeben lassen.
Es erinnert in der Nutzung an printf bzw. CString::Format und ist deswegen sehr einfach zu handhaben.

Wenn Sie sehen möchten, welchen Inhalt ihre Variablen haben, können Sie das ganz einfach ausgeben lassen:

int nZahl = 10;
CString strText = "Die Zahl ist";
TRACE("%s: %d\n", strText, nZahl);

Sie sollten das "\n" nicht vergessen, sonst haben Sie einen langen Text in der Ausgabe.

Das eingebaute TRACE ist soweit ja sehr schön, es gibt aber ein paar Gründe, ein eigenes zu schreiben, was das Original nutzt, aber etwas mehr kann.

TRACE kann keine BOOL oder bool.
TRACE kann kein Datum.
Wollen Sie nachträglich noch in eine Datei tracen, ist es weniger Arbeit.
Sie können sich alles Mögliche einfallen lassen, was Ihnen das Leben erleichtert.

__________________________________________________________________________________________________

Lokale Überwachung
In der lokalen Überwachung finden Sie alle im aktuellen Zusammenhang bekannten Variablen und, wenn Sie sich mit F10 bewegen, auch die Rückgabewerte von gerade ausgeführten Funktionen.
Hat sich ein Wert eben gerade geändert, wird er rot dargestellt.

Die Überwachung können Sie einblenden, indem Sie im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Überwachung" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Überwachung" wählen
Alt + 3 drücken.

__________________________________________________________________________________________________

Variableninhalte überwachen
In der Überwachung können Sie sich alle Variablen zusammensammeln, die Sie beobachten möchten.
Ist eine Variable nicht gültig, wird dies angezeigt, sonst ihr Inhalt.
Sie sparen sich so die ständige Suche, wo denn welche Variable gerade in der lokalen Überwachung steht.
Außerdem können Sie auch direkt nur Membervariablen von Klassen beobachten und müssen nicht ständig die Klasse aufklappen.

Die Überwachung können Sie einblenden, indem man im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Variablen" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Variablen" wählen
Alt + 4 drücken.

__________________________________________________________________________________________________

Sonderfälle beim Debuggen
Sobald Sie die Anzeige Ihres Programms debuggen wollen, werden Sie schnell ein Problem haben.
Ein Breakpoint in OnPaint oder OnUpdateCommandUI-Funktionen mutiert zu einer "Endlosschleife".
OnCtlColor ist ebenfalls ein Problemfall, da es sehr häufig pro Neuzeichnen aufgerufen wird.
Dies sind drei Beispiele, denen Sie häufiger begegnen werden.

Um diese zu debuggen, müssen Sie Ihr Programm und das VC so auf dem Bildschirm platzieren, dass sie sich nicht überschneiden.
Wer eine Mehrschirmlösung hat ist hier klar im Vorteil, besonders bei großen Fenstern.

Der Grund dafür ist übrigens sehr einfach:
Nehmen wir an, Sie haben einen Breakpoint in OnPaint.
OnPaint wird immer aufgerufen, wenn das Fenster neu angezeigt werden muss. Es passiert nun folgendes:
1.) Das Programm startet
2.) Das Fenster wird angezeigt
3.) Sie laufen auf den Breakpoint auf
4.) Sie lassen das Programm mit F5 weiterlaufen
5.) GOTO 2.

OnUpdateCommandUI zu debuggen wird besonders bei Toolbarbuttons zur Qual, denn die werden ständig aktualisiert.
__________________________________________________________________________________________________

Endlosschleifen debuggen
Ihr Programm hängt und Sie haben keine Ahnung, warum?
Dann halten Sie es einfach an. Der Befehl dazu ist im Menü "Debug": "Anhalten"
__________________________________________________________________________________________________

Wenn Fehler beim Debug nicht mehr auftreten
Sie wollen einen Fehler suchen, aber immer wenn Sie ihm im Debugger auf die Schliche kommen wollen, ist er weg?
Dann ist es einer der schwierigeren Sorte.

Eine Möglichkeit ist, dass einfach ein Neuzeichnen des Fensters nötig ist.
Dann haben Sie irgendwo ein Invalidate vergessen. So einfach die Erklärung ist, man kann bei der Suche verzweifeln.

Eine andere Möglichkeit ist, dass der Fehler nur auftritt, wenn das Programm mit normaler Geschwindigkeit läuft.
Da Sie beim Debuggen immer wieder anhalten, werden Sie den Fehler auf diese Weise wohl nie finden. Dann sollten Sie zu TRACEs und evtl. bedingten Breakpoints greifen.
__________________________________________________________________________________________________

Ich habe einen Fehler in der MFC gefunden...
Oh, Sie haben echt was drauf - bewerben Sie sich schnell bei Microsoft... äh nein, war ein Scherz.
Es klingt zwar überheblich, aber in der MFC sind keine Fehler. Davon können Sie einfach ausgehen und müssen dort nicht suchen.

Sollte es mal so scheinen, dann haben Sie verschiedene Möglichkeiten:

Lassen Sie erst einmal ein "Rebuild All" / "Alles neu erstellen" machen
Haben Sie schon den aktuellsten Service Pack für Ihr VC installiert? Nein? Dann holen Sie das nach.

Sollte das alles nicht helfen, haben Sie irgendwo einen Fehler in Ihrem Quellcode.
__________________________________________________________________________________________________

Der Debugger spinnt
Breakpoints, die Sie setzen, landen ein paar Zeilen höher oder tiefer?
Beim Debuggen werden Teile übersprungen, die eigentlich durchlaufen werden müssten, weil sie in keiner if oder Schleife stehen?
Dann nehmen Sie sich eine Tasse Kaffee und wählen im Menü "Erstellen" - "Alles neu erstellen" (Rebuild All).
Dieser Befehl sollte immer Ihre erste Wahl bei unerklärlichen Fehlern sein, denn leider ist Visual C++ nicht ganz fehlerfrei (oder wie Sie dieses Verhalten auch immer nennen wollen) und kommt manchmal durcheinander.

Sollte das nicht geholfen haben, können Sie bei VC6 noch die ncb und die opt Datei löschen (vorher schließen Sie bitte das Projekt).
Sollten Sie in der Klassenansicht mit Ordnern arbeiten, machen Sie vorher ein Backup, denn die Ordner sind dann weg.
__________________________________________________________________________________________________

Änderungen übernehmen und weiterdebuggen
Ihnen wird von Microsoft die Möglichkeit gegeben, während des Debuggens den Code zu ändern und danach mit den vorgenommenen Änderungen weiterzuarbeiten.
Auch Variableninhalte lassen sich ändern, das ist bei Schleifen manchmal praktisch, wenn Sie ein bestimmtes Verhalten provozieren wollen.
Das klingt zwar alles ganz toll - aber ich persönlich vertraue der Technik nicht und starte immer wieder von vorne.
__________________________________________________________________________________________________

Debuggen der Release-Version
Sie sind fertig, erstellen die Release-Version und... nichts geht mehr. In der Debug ist aber alles in Ordnung und den Artikel bei Codeproject haben Sie sich auch zu Herzen genommen?

Dann können Sie in den Projekteinstellungen die Debuginfos zuschalten und die Release-Version ganz normal debuggen.
Der feine Unterschied ist, dass jetzt aber _DEBUG nicht mehr definiert ist und die ganzen "Hilfestellungen" dadurch wegfallen. Falls Sie also unsauber programmiert haben, beispielsweise Zeiger nicht initialisiert haben, dann rächt sich das jetzt.

Für mehr Informationen lesen Sie bitte auch diesen Artikel.

Das Programm läuft bei Ihnen im Testbetrieb fehlerfrei, aber beim Kunden will es partout nicht laufen?
Tja, dort können Sie nicht mal eben ein Visual C++ installieren und gucken was los ist.
Bevor Sie nun per Remote-Debug auf Fehlersuche gehen, haben Sie noch eine Möglichkeit:
Sie bauen im Programm kleine Messageboxen ein, die Ihnen an wichtigen Stellen Informationen geben (für so eine Suche brauchen Sie aber einen Kunden mit guten Nerven), oder Sie lassen die Infos in eine Datei ausgeben.
Egal für was Sie sich an dieser Stelle entscheiden, es wäre sinnvoll gewesen, das schon von Anfang an vorzubereiten, indem Sie sich eigene Helferfunktionen (z.B. ein TRACE) geschrieben hätten, denn dann wäre eine Ausgabe in eine Datei nur ein geringer Aufwand.
__________________________________________________________________________________________________

Threads wechseln
Oft laufen (auch wenn Sie das gar nicht eingebaut haben) mehrere Threads parallel ab.
Hin und wieder landen Sie beim Unterbrechen im falschen und müssen wechseln.
Das geht im Menü "Debug" - "Threads".
Doppelklicken Sie dort einfach auf den gewünschten Thread und Sie werden an die aktuelle Position im Quellcode gebracht.
__________________________________________________________________________________________________

Bei Ausnahmen unterbrechen
Sie sehen in der Debug-Ausgabe dauernd Zeilen wie

Nicht abgefangene Ausnahme in ...

können aber nicht finden, wo der Fehler ist?
Dann können Sie im Menü "Debug" mit "Ausnahmen..." ein Dialogfeld aufrufen, wo Sie einstellen können, wie sich der Debugger bei welcher Ausnahme verhalten soll:

Immer anhalten
Anhalten, wenn sie nicht behandelt wurde

__________________________________________________________________________________________________

Das Debuggen beenden
Wenn Sie das Programm vorzeitig beenden wollen, etwa weil Sie ohne den Debugger den Code ändern möchten oder es auch einfach nicht mehr stabil laufen will, dann können Sie das mit "Debug beenden" im Menü Debug.
__________________________________________________________________________________________________

Was Sie noch gelesen haben sollten

jQT- Debuggen im Borland C++ Builder
Eine sehr schön erklärte und bebilderte Einführung, die man mit wenigen Anpassungen für Visual C++ übernehmen kann. (Danke @ junix)
Artikel zum Debuggen bei Codeproject
Codeproject ist wohl die Anlaufstelle für ratlose oder Ideen suchende Entwickler. Und natürlich haben sie auch etwas zum Thema Debuggen zu bieten.
Verwenden des Debuggers in der MSDN
Debuggen der Release-Version
Eine Erklärung mit einigen guten Links. Der Artikel ist auf jeden Fall lesenswert. (Danke @ Redhead)

estartu

So, ich bin jetzt mit Suchen drübergegangen und habe nur noch ausgewählte "man" übrig gelassen.
Guckt nochmal jemand bitte drüber?

Mr. B

Sobald ich zu Hause bin und wieder mehr Zeit habe, kann ich das machen. Allerdings auch nur, wenn das die LETZTE Version sein wird und die nachher nicht mehr veränddert wird.

Mr. B

estartu

Naja, es soll ja auch fachlich nochmal durchgelesen werden - nur irgendwie haperts da scheinbar noch in der Besetzung.
Ich nehme das R mal raus und frage Montag Shade, ob er sich da mal kümmert.

Wenns wieder da ist, darfst du dann endgültig ran.

Shade Of Mine

was mir aufgefallen ist:

Was bringt mir jetzt ein Breakpoint?

bei TRACE waere eine erwaenung von __FILE__ __LINE__ und __FUNCTION__ (oder wie dieses makro unter vc++ auch immer heissen mag) praktisch.

zur fachlichen richtigkeit kann ich nicht viel sagen weil die ganzen VC++/MFC spezifischen sachen mir komlett fremd sind. ich habe aber im mod forum mal Unix-Tom und dEUs angeschrieben ob sie das korrekturlesen wollen. wenn sie nicht wollen werde ich oeffentlich fragen. irgendwie bekommst du schon noch deine korrekturleser

grammatikalisch und rechtschreibtechnisch haben wir ja schon top leute

estartu

Okay, die Makros muss ich dann wohl mal nachgucken - die kenne ich nämlich noch nicht, aber ich glaube, ich hab sie irgendwo schon gelesen...

dEUs

Ich bin soweit damit einverstanden, bis auf deine ständigen Wechsel zwischen "du" und "Sie". Habe allerdings nur den ursprünglichen Artikel gelesen, wenn das in der Zwischenzeit korrigiert ist, ist es ja ok.

Eine Sache würde ich noch mit aufnehmen:
Shift-F11. Gerade bei den von dir angesprochenen Konstruktoren sehr praktisch.
Bei Verify würde ich vielleicht etwas deutlicher herausstellen, dass es im Grunde ein TRACE ist. Nur eben, dass der darin enthaltene Quellcode nicht weggeschmissen wird. Du hast es schon indirekt drin, aber vielleicht kannst du es noch ein wenig verdeutlichen.

estartu

@dEUs: Okay, danke. Das Shift+F11 mache ich immer per Symbol - daher merk ich mir das nie.
Ich trags noch nach.

Die Wechsel sind raus, der aktuelle Artikel steht hier auf Seite 2.
@Shade: Sollte man das irgendwie kennzeichnen?

Ich mach die Korrekturen dann Morgen.

Shade Of Mine

estartu_de schrieb:

Die Wechsel sind raus, der aktuelle Artikel steht hier auf Seite 2.
@Shade: Sollte man das irgendwie kennzeichnen?

ne, kennzeichnen ist unnoetig. ich hab "wie man korrigiert" mal ergaenzt. es wird immer nur die letzte version korrigiert.

estartu

Worum geht's hier?
Über Programmieren im Sinne von "Quellcode erstellen" gibt es unzählige Bücher.
Über das Finden und Beheben von Fehlern leider nicht, obwohl es genauso wichtig ist und auch einen großen Anteil am Arbeitsleben eines Softwareentwicklers hat.
Denn auch nach mehreren Jahren als Softwareentwickler ist das Debuggen von Anwendungen eine tägliche Aufgabe, da man wohl nie auf Anhieb fehlerfreien Code produziert.
Im Laufe der Jahre eignet man sich als debuggender Entwickler viele Tricks und Kniffe an, die auch Anfänger zu Beginn ihrer "Laufbahn" schon gut gebrauchen könnten.
In diesem Artikel erfahren Sie von mir die ersten Grundlagen und ich werde Ihnen den oftmals steinigen Weg des Debuggens zeigen.

Ich möchte in diesem Artikel alles zusammentragen, was mir bisher zum Debuggen bekannt ist.
Angefangen bei den Grundlagen bis hin zu häufigen Fehlern, die sich im Debugger erkennen lassen, und auch Techniken, mit denen Sie sich die Fehlersuche erleichtern können.
Aber auch auf "Macken und Eigenheiten" des Debuggers werde ich eingehen.

Dieser Artikel bezieht sich auf Visual C++ 6 (SP6). Sie sollten aber eigentlich alles ohne Probleme auch in den Nachfolgerversionen finden können.
Natürlich haben auch andere Entwicklungsumgebungen (auch von anderen Programmiersprachen) einen Debugger und vieles von hier werden Sie übertragen können.

Englisch ist die Sprache aller Softwareentwickler, daher verwende ich überwiegend die englischen Fachausdrücke in diesem Artikel. Soweit möglich ergänze ich diese auch um die deutsche Übersetzung.
__________________________________________________________________________________________________

Was ist der Debugger?
Der Debugger ist ein Teil von VC, der Ihnen hilft, Fehler zu finden.
Sie können dem Programm direkt "bei der Arbeit" zuschauen.
Da so ein Programm aber schnell sehr komplex wird, gibt es unzählige Hilfsmittel.
__________________________________________________________________________________________________

Haltepunkte / Breakpoints
Ein Breakpoint ist eine Marke (roter Punkt), wo das Programm in der Ausführung unterbrochen wird, wenn die so markierte Anweisung an der Reihe ist.
Sie können mit Hilfe von Breakpoints das Programm anhalten, sobald die markierte Zeile ausgeführt werden soll. Dann können Sie sich die aktuellen Variableninhalte anschauen oder auch, von wo diese Funktion gerade aufgerufen wurde.
Das ist dann praktisch, wenn Sie eine bestimmte Stelle schon unter Verdacht haben.

Sie können Breakpoints mit F9 setzen und auch wieder entfernen.
Außerdem gibt es einen Dialog zum Verwalten aller Breakpoints; Sie erhalten ihn über

Strg + B
Alt + F9
Menü "Bearbeiten" -> "Haltepunkte..."

Zusätzlich gibt es noch die Symbolleiste "Debug", die Sie über "Anpassen" noch um viele nützliche Schaltflächen erweitern können (und sollten).
Da die Symbolleistenbefehle auch im Menü zu finden sind, werde ich sie ab jetzt nicht mehr erwähnen.

Breakpoints funktionieren nur, wenn das Programm auch im Debugmodus gestartet wurde. Das geht mit

F5
Menü "Erstellen" - "Debug starten" -> "Ausführen"

Es gibt noch die Möglichkeit, den Debug mit F10 oder F11 zu starten, das bietet sich bei komplexen Programmen aber nicht an.

Sie können einzelne Breakpoints auch nur unter einer Bedingung aktivieren.
Das ist in dem Fall nützlich, wenn Sie sich beispielsweise eine for-Schleife erst ab dem 1000. Durchlauf ansehen möchten.
Die Bedingung können Sie in dem o.g. Dialog festlegen.
Hier können Sie auch angeben, beim wievielten Mal "am Breakpoint vorbeikommen" das Programm erst angehalten werden soll.
__________________________________________________________________________________________________

Bewegungsmöglichkeiten in der Ausführung
Da Sie ja sicherlich nicht nur den Zustand des Programms zu dem Zeitpunkt, wo der Breakpoint sitzt, beobachten wollen, können Sie auch schrittweise weitermachen.

Das geht mit

F10: Eine Anweisung weiter
F11: In die Funktion springen
Shift+F11: Bis zum Rücksprung weiterlaufen
und weiteren Befehlen im Menü "Debug"

Welcher dieser Befehle angebracht ist, hängt von der jeweiligen Situation ab.
Meistens werden Sie F10 nutzen, aber wenn Sie sehen möchten, was in einer Funktion mit ihren Variablen gemacht wird, dann brauchen Sie F11 und unter Umständen viel Geduld, denn für jeden Parameter laufen Sie erst einmal durch den passenden Konstruktor, bevor Sie in der Funktion landen, die Sie ansehen wollten.
Für diesen Fall ist die Tastenkombination Shift+F11 sehr praktisch, da sie damit das Programm bis zum Rücksprung aus der aktuellen Funktion weiterlaufen lassen.

Dafür hat dies aber den Vorteil, dass Sie nach und nach sehr viel über die innere Funktionsweise der MFC lernen, und je öfter Sie sich in die "Innereien" vorwagen, desto sicherer werden Sie sich bewegen können.
__________________________________________________________________________________________________

Aufrufliste / Callstack
Der Callstack ist ein Unterfenster vom VC, in dem bei angehaltener Programmausführung gezeigt wird, welche Funktion welche mit was für Parametern aufgerufen hat, bis zu der Stelle, wo Sie gerade "stehen".
Die aufgerufene Funktion steht immer über der aufrufenden.

CAd3App::InitInstance() line 124
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133ef5, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e98989()

Den Callstack können Sie einblenden, indem Sie im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Aufrufliste" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Aufrufliste" wählen
Alt + 7 drücken.

Nicht alle Zeilen im Callstack sind normal lesbar. Bei einigen steht da etwas wie

KERNEL32! 77e98989()

Darauf können Sie auch doppelklicken, aber Sie werden nur Assemblercode zu sehen bekommen. Für diese Funktionen gibt es keinen Quellcode.

Der kleine grüne Pfeil am linken Rand im Editor zeigt, welcher Befehl gerade an der Reihe ist. Allerdings ist er nur dann auf dem aktuellen Befehl, wenn Sie in der allerobersten Funktion stehen.
Wenn Sie per Doppelklick auf die gewünschte Zeile im Callstack in eine andere Funktion wechseln, dann zeigt er immer auf die Zeile, die als nächstes ausgeführt werden soll.
__________________________________________________________________________________________________

Gültigkeitsannahmen (ASSERT)
ASSERTs dienen zu Prüfung, ob für die Programmausführung nötige Werte eingehalten werden.
Ein ASSERT löst dann eine Meldung aus, wenn die Bedingung in den Klammern nicht erfüllt ist. Wollen Sie z.B. immer benachrichtigt werden, schreiben Sie

ASSERT(FALSE);

wogegen

ASSERT(TRUE);

ziemlich sinnlos ist.

Sie sollten so beispielsweise Zeiger grundsätzlich prüfen:

int* pInt = NULL;
ASSERT(pInt); // für Schreibfaule
ASSERT(pInt != NULL); // für Perfektionisten

Dieser Code würde eine Assertion produzieren, die von Anfängern auch gerne als Fehlermeldung bezeichnet wird. Bei der Meldung haben Sie aber die Möglichkeit, "Wiederholen"/"Retry" zu drücken und werden genau auf der Zeile mit dem ASSERT landen, der die Meldung ausgelöst hat.
Damit solche Prüfungen möglich sind, müssen Sie aber sorgfältig arbeiten, denn das hier würde keine Assertion auslösen:

int* pInt; // Initialisierung vergessen
ASSERT(pInt);

So ist der ASSERT eine gute Möglichkeit, sich um Fehler zu kümmern bevor das Programm abstürzt.
Sie lassen sich einfach durch ASSERTs melden, wenn das Programm wegen eines fehlerhaften Variableninhalts nicht mehr fehlerfrei ausgeführt werden kann.
Tritt dieser Zustand ein, werden Sie als Entwickler darauf hingewiesen und können sich das Problem "am lebenden Objekt" ansehen.

ASSERT ist ein Befehl, der nur in der Debugversion funktioniert.
Daher dürfen Sie in den Klammern nichts schreiben, was für die Releaseversion wichtig ist.
Also machen Sie bitte niemals sowas:

ASSERT(SpeichereMeineDaten(CFile* f_datei));

Dazu lesen Sie aber am besten auch Surviving the Release Version bei Codeproject.
__________________________________________________________________________________________________

Der ASSERT steht in MFC Quellcodes, was nun?
Sie haben auf "Wiederholen" gedrückt und stehen nun mitten im fremden Quellcode?
Dann gehen Sie doch im Callstack in die oberste Funktion, die von Ihnen ist und schauen Sie dort mal nach dem Rechten.
Dort scheint alles okay? Hangeln Sie sich immer weiter in die jeweils aufrufende Funktion, denn irgendwo ist der Fehler schon versteckt.

So ein ASSERT hat in der MFC entweder einen Kommentar oder er lässt sich fast wie im Klartext lesen. Ein

ASSERT(IsWindow(...));

zeigt Ihnen, dass Sie nach irgendwas suchen müssen, was mit einem Zugriff auf ein Fenster zu tun hat.
__________________________________________________________________________________________________

Geprüfte Befehle (VERIFY)
Sie können sich auch benachrichtigen lassen, falls eine Funktion einen bestimmten Wert zurückgibt.
Sicher könnten Sie das auch mit ASSERT machen, aber das gäbe ja Probleme in der Release-Version.

Gegenüber dem o.g. Beispiel ist es aber vollkommen okay

VERIFY(SpeichereMeineDaten(CFile* f_datei));

zu schreiben.
__________________________________________________________________________________________________

Die Debugausgabe
Wenn Sie noch unter DOS programmieren gelernt haben, werden Sie es noch kennen, dass man im Zweifelsfall kleine Ausgaben gemacht hat, um zu sehen, ob das Programm auch hinter den Kulissen tut, was es soll.
Das geht z.B. bei einer SDI ja gar nicht mehr so einfach und außerdem hat sich Microsoft etwas praktisches einfallen lassen, was die Hilfsausgaben von den eigentlichen Ausgaben trennt: Die Debugausgabe.

Die Debugausgabe können Sie einblenden, indem Sie

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Ausgabe" setzen
im Menü "Ansicht" - "Ausgabe" wählen
Alt + 2 drücken.

Dort gibt die MFC schon automatisch Informationen aus und Sie können das auch.
__________________________________________________________________________________________________

Hilfsausgaben (TRACE)
Mit TRACE können Sie sich beliebige Daten in der Debugausgabe ausgeben lassen.
Es erinnert in der Nutzung an printf bzw. CString::Format und ist deswegen sehr einfach zu handhaben.

Wenn Sie sehen möchten, welchen Inhalt ihre Variablen haben, können Sie das ganz einfach ausgeben lassen:

int nZahl = 10;
CString strText = "Die Zahl ist";
TRACE("%s: %d\n", strText, nZahl);

Sie sollten das "\n" nicht vergessen, sonst haben Sie einen langen Text in der Ausgabe.

Das eingebaute TRACE ist soweit ja sehr schön, es gibt aber ein paar Gründe, ein eigenes zu schreiben, was das Original nutzt, aber etwas mehr kann.

TRACE kann keine BOOL oder bool.
TRACE kann kein Datum.
Wollen Sie nachträglich noch in eine Datei tracen, ist es weniger Arbeit.
Sie können sich alles Mögliche einfallen lassen, was Ihnen das Leben erleichtert.

__________________________________________________________________________________________________

Weitere nützliche Makros
Damit Sie Ihre Debugausgaben noch etwas verfeinern können, gibt es noch einige Makros:

__DATE__ : Das Datum, wann diese Zeile kompiliert wurde.
__FILE__ : Der Name der Datei, in der sich diese Zeile befindet.
__TIME__ : Der Zeitpunkt, wann diese Datei zuletzt compiliert wurde.
__LINE__ : Die Zeilennummer.

Es gibt noch weitere Makros, schauen sie ruhig mal in die MSDN. Sie stehen alle in einem Kapitel.
__________________________________________________________________________________________________

Lokale Überwachung
In der lokalen Überwachung finden Sie alle im aktuellen Zusammenhang bekannten Variablen und, wenn Sie sich mit F10 bewegen, auch die Rückgabewerte von gerade ausgeführten Funktionen.
Hat sich ein Wert eben gerade geändert, wird er rot dargestellt.

Die Überwachung können Sie einblenden, indem Sie im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Überwachung" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Überwachung" wählen
Alt + 3 drücken.

__________________________________________________________________________________________________

Variableninhalte überwachen
In der Überwachung können Sie sich alle Variablen zusammensammeln, die Sie beobachten möchten.
Ist eine Variable nicht gültig, wird dies angezeigt, sonst ihr Inhalt.
Sie sparen sich so die ständige Suche, wo denn welche Variable gerade in der lokalen Überwachung steht.
Außerdem können Sie auch direkt nur Membervariablen von Klassen beobachten und müssen nicht ständig die Klasse aufklappen.

Die Überwachung können Sie einblenden, indem man im Debugmodus

auf einer leeren Stelle einer Symbolleiste das Kontextmenü aufrufen und dort das Häkchen bei "Variablen" setzen
im Menü "Ansicht" - "Debug-Fenster" -> "Variablen" wählen
Alt + 4 drücken.