Ein Suspect Commit ist eine Änderung, die bei der Fehlersuche als mögliche Ursache eines Problems infrage kommt. „Suspect“ bedeutet dabei lediglich verdächtig: Ein zeitlicher oder technischer Zusammenhang liefert einen Hinweis, beweist aber noch nicht, dass diese Änderung den Fehler tatsächlich verursacht hat.
Was ist ein Commit?
In Versionsverwaltungssystemen wie Git bezeichnet ein Commit einen gespeicherten Änderungssatz. Du kannst darin beispielsweise mehrere zusammengehörende Änderungen am Programmcode sichern und mit einer Beschreibung versehen.
Perforce P4 verwendet dafür ein etwas anderes Konzept. Dort werden zusammengehörende Änderungen in einer Changelist organisiert. Nach dem Einreichen gehört die Changelist zur dokumentierten Versionsgeschichte des Projekts.
Die Begriffe Commit und Changelist sind deshalb nicht vollständig austauschbar. Im Zusammenhang mit der Fehlersuche beschreibt „Suspect Commit“ allgemein eine Änderung, die als möglicher Ausgangspunkt eines Fehlers untersucht wird.
Warum wird eine Änderung zum Verdächtigen?
Angenommen, Build 120 deines Spiels funktioniert. Nach einigen Änderungen entsteht Build 121, der beim Öffnen einer Tür abstürzt. Damit liegt der Verdacht nahe, zunächst die Änderungen zwischen beiden Builds zu untersuchen.
Eine davon betrifft beispielsweise die Türlogik. Da der Crash ebenfalls beim Öffnen einer Tür auftritt, besteht zusätzlich ein inhaltlicher Zusammenhang. Diese Änderung ist damit ein sinnvoller Kandidat für die weitere Untersuchung.
Verdächtig kann eine Änderung also unter anderem deshalb sein, weil sie kurz vor dem erstmaligen Auftreten eines Fehlers vorgenommen wurde oder weil sie einen Codebereich betrifft, der mit dem beobachteten Problem zusammenhängt.
Ein Suspect Commit ist noch keine Ursache
Die Bezeichnung kann leicht missverstanden werden. Ein Suspect Commit ist keine bereits überführte fehlerhafte Änderung. Er stellt zunächst eine Hypothese für die Fehlersuche dar.
Vielleicht wurde die Türlogik unmittelbar vor dem Crash verändert. Trotzdem könnte die eigentliche Ursache in einer älteren Änderung des Inventarsystems liegen. Erst die neue Türfunktion löst einen bereits vorhandenen fehlerhaften Zustand aus.
Deshalb solltest du eine verdächtige Änderung untersuchen, statt sie allein aufgrund ihres Zeitpunkts als Ursache zu behandeln.
Wie grenzt du verdächtige Änderungen ein?
Ein guter Ausgangspunkt sind zwei bekannte Entwicklungsstände: einer, in dem das Problem noch nicht auftritt, und einer, in dem es bereits vorhanden ist. Die Versionsverwaltung zeigt dir anschließend, welche Änderungen dazwischen liegen.
Je kleiner dieser Zeitraum ausfällt, desto weniger Änderungen musst du zunächst berücksichtigen. Weißt du beispielsweise, dass Build 120 funktioniert und Build 121 fehlerhaft ist, kannst du dich auf die Unterschiede zwischen diesen beiden Builds konzentrieren.
Stack Traces liefern weitere Hinweise
Ein Stack Trace kann die Suche weiter eingrenzen. Er zeigt die Folge der Funktionsaufrufe zum Zeitpunkt eines Fehlers und führt dich dadurch möglicherweise zu einem bestimmten Bereich des Programmcodes.
Verweist der Stack Trace beispielsweise auf eine Funktion für die Türinteraktion und wurde genau diese Datei kürzlich verändert, erhält die betreffende Änderung zusätzliche Aufmerksamkeit.
Auch hier gilt: Der Stack Trace zeigt, wo ein Fehler sichtbar wurde. Die ursprüngliche Ursache kann an einer anderen Stelle entstanden sein.
Logs ergänzen die Untersuchung
Log-Dateien dokumentieren Ereignisse während der Programmausführung. Dadurch kannst du untersuchen, was unmittelbar vor einem Fehler geschah.
Meldet das Log beispielsweise zunächst einen fehlenden Inventargegenstand und folgt anschließend der Absturz der Türinteraktion, solltest du neben der Türlogik auch das Inventarsystem berücksichtigen. Der erste Verdacht erweitert sich damit um weitere mögliche Ursachen.
Suspect Changelists in Perforce
Bei Perforce steht statt eines klassischen Git-Commits häufig die Changelist im Mittelpunkt. Sie fasst Dateien zusammen, die gemeinsam für eine Aufgabe verändert und eingereicht wurden.
Führt die Untersuchung zu einer bestimmten Datei, kannst du über ihre Versionsgeschichte herausfinden, in welchen Changelists sie verändert wurde. Anschließend lässt sich prüfen, welche weiteren Dateien zur jeweiligen Änderung gehörten.
Das kann neue Zusammenhänge sichtbar machen. Eine vermeintlich kleine Änderung an der Tür könnte beispielsweise gemeinsam mit Anpassungen am Inventarsystem eingereicht worden sein.
Automatische Zuordnung durch Fehlererfassungssysteme
Bei größeren Projekten muss die Suche nach relevanten Änderungen nicht ausschließlich manuell erfolgen. Fehlererfassungssysteme können Informationen über einen Fehler mit Daten aus der Versionsverwaltung verbinden.
Dabei lassen sich beispielsweise Dateien aus einem Stack Trace mit ihrer Änderungsgeschichte vergleichen. Änderungen, die für den betroffenen Bereich relevant erscheinen, können anschließend als mögliche Kandidaten für die Untersuchung hervorgehoben werden.
Eine solche automatische Zuordnung liefert eine Vorauswahl. Sie ersetzt nicht die technische Prüfung durch das Entwicklungsteam.
Wie prüfst du einen Suspect Commit?
Nachdem du eine verdächtige Änderung gefunden hast, beginnt die eigentliche Prüfung. Zuerst solltest du nachvollziehen, was darin verändert wurde und welchem Zweck die Änderung diente.
Anschließend kannst du eine konkrete Hypothese formulieren. Statt „Diese Änderung verursacht den Crash“ lautet sie beispielsweise: „Die neue Schlüsselprüfung übergibt unter bestimmten Bedingungen keinen gültigen Gegenstand an die Türlogik.“
Diese Annahme lässt sich gezielt testen. Bestätigt sich die Hypothese nicht, schließt du die Änderung als Ursache aus oder untersuchst einen anderen Zusammenhang. Auf diese Weise verkleinert sich der Kreis der möglichen Fehlerquellen Schritt für Schritt.
Zurücksetzen allein reicht nicht immer
Eine verdächtige Änderung testweise zurückzunehmen kann bei der Untersuchung helfen. Verschwindet der Fehler anschließend, spricht das für einen Zusammenhang. Auch dieses Ergebnis muss jedoch richtig eingeordnet werden.
Eine Änderung kann beispielsweise lediglich einen zuvor verborgenen Fehler sichtbar gemacht haben. Durch das Zurücksetzen verschwindet dann zwar der Crash, die eigentliche Schwachstelle bleibt aber im Projekt bestehen.
Deshalb gehört zum Debugging mehr als das Entfernen der zuletzt vorgenommenen Änderung. Ziel ist es, die tatsächliche Ursache zu verstehen und gezielt zu korrigieren.
Vom Verdacht zur Fehlerkorrektur
Ein Suspect Commit verbindet mehrere Teile der Fehlersuche miteinander. Ein Crash oder Bug liefert den Ausgangspunkt. Logs und Stack Trace grenzen das technische Umfeld ein. Die Versionsverwaltung zeigt anschließend, welche Änderungen an den betroffenen Bereichen vorgenommen wurden.
Aus diesen Informationen entsteht eine Liste möglicher Kandidaten. Du untersuchst sie, testest deine Hypothesen und bestätigst oder verwirfst den jeweiligen Verdacht.
Findest du schließlich die Ursache, kannst du sie korrigieren und einen neuen Build erzeugen. Anschließende Tests zeigen, ob der ursprüngliche Fehler verschwunden ist und ob die Korrektur unbeabsichtigte neue Probleme verursacht.
Weitere Artikel auf Games und Lyrik
Wenn du dich neben der technischen Spieleentwicklung auch für klassische Adventures interessierst, findest du auf Games und Lyrik weitere Beiträge. In Runaway 3: A Twist of Fate begleitest du Brian und Gina durch ein Point-and-Click-Adventure mit Rätseln, ungewöhnlichen Situationen und einer Geschichte voller Wendungen.
Weitere Informationen darüber, wie Fehlerdaten mit Informationen aus der Softwareentwicklung verbunden werden können, findest du auf der offiziellen Website von Sentry.
