Bei der Jagd nach Bugs im eigenen Programmcode holen sich Entwickler gern Hilfe. Etwa beim DDD: Er stöbert das virtuelle Ungeziefer auf und gibt den Blick frei auf alle Daten, die das Programm produziert.

Bug gefunden

Erfahrene C-Programmierer werden es längst ahnen und sehen sich nun bestätigt: Grund für den Absturz ist ein Fehler beim Indizieren des Array. Ein Array mit sechs Elementen läuft von 0 bis 5. Im Falle von »j==5« erfolgt ein Zugriff auf »arrIn[j+1]« und damit auf »arrIn[6]«. Das Feld liegt aber jenseits der Array-Grenzen.

Der Fehler steckt in der Abbruchbedingung der For-Schleife: »j« dürfte nur bis »nrElements-<$>1« laufen. Statt sofort den Quelltext zu korrigieren und das Programm neu zu übersetzen ist es sinnvoller, die Vermutung zunächst im laufenden Programm zu überprüfen. Das geht mit DDD-Bordmitteln: Der Debugger kann die Variable »nrElements« um 1 vermindern und die Routine noch einmal von Anfang an laufen lassen.

Für den bequemen Zugriff auf den Wert einer Variablen empfiehlt es sich, sie ins Data-Fenster aufzunehmen. Also: »nrElements« im Quelltext markieren und »Display« drücken (oder doppelt auf die Variable klicken). Danach den Eintrag im Data-Window markieren, sein Kontextmenü öffnen, den Punkt »Set value...« wählen und »5« eintragen.

Anschließend den Cursor im Quelltext an den Anfang der Zeile 8 setzen (vor die While-Anweisung) und im Kontextmenü die Option »Set Execution Position« wählen. Damit wird Zeile 8 zur aktuellen Position und ein »Cont« führt das Programm korrekt zu Ende.

Wie sich der Debugger verhält, wenn er einen Breakpoint erreicht, ist im DDD frei konfigurierbar, er kann weit mehr als nur den Prozesses anhalten. Neben den bedingten Haltepunkten findet sich im Properties-Fenster (Abbildung 3) die Option »Ignore Count«. Mit ihr hält der Debugger erst dann an, wenn das Programm den Breakpoint mehrmals überschritten hat.

Breakpoint-Magie

Besonders mächtig ist der Punkt »Commands«: Damit setzt der Debugger automatisch DDD-Kommandos ab, sobald das Benutzerprogramm einen Haltepunkt erreicht. Sinnvoll ist das zum Beispiel, um den Wert einer Variablen auszugeben und dann mit »Cont« die Ausführung fortzusetzen. Das ersetzt »printf()«-Kommandos im Quelltext. Der Benutzer könnte beim Erreichen eines Haltepunkts auch automatisch andere Breakpoints aktivieren.

Wer beim Debugging seines Programms viele Breakpoints braucht, den Inhalt mehrerer Variablen verfolgt und einige Bedingungen eingefügt hat, will das nicht bei jedem DDD-Start erneut einstellen. Muss er auch nicht, da DDD seine Sitzungen speichert: Per »File | Save Session as...« landen alle Einstellungen auf der Festplatte, nach einem Neustart holt »File | Open Session« die alte Konfiguration zurück.

In den Menüs des DDD finden sich noch viele weitere praktische Perlen, besonders das grafische Darstellen von Daten ist eine Stärke des DDD. Das hilft dabei, komplizierte Datenstrukturen besser zu verstehen. Abbildung 4 zeigt einen Ausschnitt einer dynamischen Baumstruktur. Per Doppelklick auf die Zeiger navigiert der Benutzer bequem durch die Strukturen. Damit sieht er beispielsweise Zyklen in verketteten Listen.

Abbildung 4: Datenstrukturen übersichtlich darstellen ist die große Stärke des DDD. Hier zeigt er eine Baumstruktur. Der Benutzer öffnet neue Zweige, indem er doppelt auf die Zeiger in den Kästchen klickt.

Bei der Jagd nach Bugs im eigenen Programmcode holen sich Entwickler gern Hilfe. Etwa beim DDD: Er stöbert das virtuelle Ungeziefer auf und gibt den Blick frei auf alle Daten, die das Programm produziert.