Dieser und noch weitere Artikel wurde von estartu erstellt.


Folgende Themen werden von diesem Artikel berührt:


Druckversion des Artikels


1 Worum geht's hier?

Über das 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 darstellt.
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.
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.

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

3 Haltepunkte / Breakpoints

Ein Breakpoint ist eine Marke , an der 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

Zusätzlich gibt es noch die Symbolleiste "Debug", die Sie über "Anpassen" noch um viele nützliche Schaltflächen erweitern können (und sollten).


Breakpoints funktionieren nur, wenn das Programm auch im Debugmodus gestartet wurde. Das geht mit
Es gibt noch die Möglichkeit, den Debug mit F10 oder F11 zu starten, das bietet sich bei komplexen Programmen aber nicht an.

Wenn es sinnvoller ist, können Sie einzelne Breakpoints auch bedingt 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 "Breakpoint-Verwaltungs-Dialog" festlegen.
Hier können Sie auch angeben, beim wievielten Mal "am Breakpoint vorbeikommen" das Programm erst angehalten werden soll.


4 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

Welcher dieser Befehle angebracht ist, hängt von der jeweiligen Situation ab.
Strg+F10 ist praktisch, wenn Sie zu der Stelle gelangen möchten, die Sie gerade betrachten, um z.B. zu sehen, ob eine Bedingung so funktioniert, wie Sie sich das vorstellen.
Im Prinzip würden sie mit F9 (Breakpoint setzen) und F5 (bis zum Breakpoint laufen) dasselbe erreichen, aber wenn Sie gerade beim Step-by-Step Debuggen sind und in eine Schleife kommen, dann können Sie den Cursor mit den Pfeiltasten aus der Schleife bewegen und sind mit Strg + F10 schnell wieder aus der Schleife raus.

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 sich ansehen wollen.
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.

5 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 bis zu der Stelle aufgerufen hat, wo Sie gerade "stehen".
Die aufgerufene Funktion steht immer über der aufrufenden.
Code:
CMyApp::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

Nicht alle Zeilen im Callstack sind normal lesbar. Einige sehen etwa so aus:
Code:
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, welche Befehlszeile 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.

6 Gültigkeitsannahmen (ASSERT)


ASSERTs dienen zur Prüfung, ob die für die Programmausführung nötigen Werte eingehalten werden. ASSERT ist "nur" ein Makro, wie auch TRACE und VERIFY. Sie erkennen das daran, dass es komplett groß geschrieben wird.
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
C++:
ASSERT(FALSE);

wogegen
C++:
ASSERT(TRUE);
ziemlich sinnlos ist.

Sie sollten so beispielsweise Zeiger grundsätzlich prüfen:
C++:
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, die 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:
C++:
int* pInt; // Initialisierung vergessen
ASSERT(pInt);

So ist ASSERT eine gute Möglichkeit, sich um Fehler zu kümmern, bevor das Programm abstürzt.
Sie lassen sich einfach durch ASSERTs mitteilen, 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.

:warning: ASSERT wird in der Release-Version durch "nichts" ersetzt.
Daher dürfen Sie in den Klammern nichts schreiben, was für die Releaseversion wichtig ist.
Also machen Sie bitte niemals so etwas:
C++:
ASSERT(SpeichereMeineDaten(CFile* f_datei));

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

6.1 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
C++:
ASSERT(IsWindow(...));


zeigt Ihnen, dass Sie nach irgendwas suchen müssen, was mit einem Zugriff auf ein Fenster zu tun hat. Eine häufige Ursache ist, dass das Fenster noch nicht oder nicht mehr existiert.

7 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 in Ordnung,
C++:
VERIFY(SpeichereMeineDaten(CFile* f_datei));
zu schreiben.

8 Die Debugausgabe

Wenn Sie noch gelernt haben, unter DOS zu progammieren, 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

Dort gibt die MFC schon automatisch Informationen aus und wie das geht, lesen Sie gleich.

8.1 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:
C++:
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.


8.2 Weitere nützliche Makros

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

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

9 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

9.1 Variableninhalte überwachen


In der Überwachung können Sie sich alle Variablen zusammensammeln, die Sie beobachten möchten.
Dazu können Sie sie aus der lokalen Überwachung oder dem Quellcode per Drag&Drop herüberziehen, den Namen eingeben oder aus dem Kontextmenü auf dem Variablennamen im Quellcode Schnellüberwachung (Quick Watch) wählen.
Wenn Sie nur "mal eben" die Variable anschauen wollen, reicht oft auch der Tooltip aus.

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 Sie im Debugmodus

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

10.1 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"
Nun können Sie sich so im Code bewegen, als wären Sie auf einen Breakpoint aufgelaufen.

10.2 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. auch bedingten Breakpoints greifen.

11 Ich habe einen Fehler in der MFC gefunden...

Oh, Sie haben echt was drauf - bewerben Sie sich schnell bei Microsoft... äh nein, Scherz beiseite.
Die MFC ist zwar nicht fehlerfrei, aber normalerweise ist der Fehler in Ihrem Code zu finden, da die MFC doch sehr gründlich getestet wurde.

Sollten Sie den Fehler trotz gewissenhafter Suche nicht finden, dann haben Sie verschiedene Möglichkeiten:
Sollte das alles nicht helfen, haben Sie doch irgendwo einen Fehler in Ihrem Quellcode.

12 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 keinem if oder keiner 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.

13 Ä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 dieser Technik nicht und starte immer wieder von vorne.

14 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 o.g. 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.

15 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" oder mit
Doppelklicken Sie in dem Dialog einfach auf den gewünschten Thread und Sie werden an die aktuelle Position im Quellcode gebracht.


16 Bei Ausnahmen unterbrechen

Sie sehen in der Debug-Ausgabe dauernd Zeilen wie
Code:
Nicht abgefangene Ausnahme in ...

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


17 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, mit oder mit Shift + F5.

18 Was Sie noch gelesen haben sollten

Sie können Kommentare zu diesem Artikel im Forum schreiben. (Eine Registrierung ist nicht notwendig.)

Logo-Design: MastaMind Webdesign