Jeder ärgert sich über Softwarefehler oder Abstürze. Verwandelt man aber den Verdruss in konstruktive Energie und meldet den Entwicklern Fehler, dann hilft das dabei, die Zahl der Ärgernisse zu verringern.

Jedem Anwender steht es frei, auch ohne Kenntnis über den Quellcode Bug Reports zu schreiben, die den Entwicklern beim Nachvollziehen von Fehlern helfen. Wenn Sie diese reproduktionstauglich beschreiben, an die richtige Stelle melden und bei Abstürzen einen sogenannten Backtrace hinzufügen, dann tragen Sie als Anwender ohne Programmierkenntnisse einen wichtigen ersten Schritt zur Fehlerbehebung bei.

In der Praxis treten Softwarefehler – im Jargon Bugs – grundsätzlich häufiger auf, als man sich das wünscht. Für die Entwickler bedeutet es eine schwierige Herausforderung, das Zusammenspiel der zigtausend Zeilen Programmcode zu verstehen, aus denen heutige Programme bestehen. Im Team müssen sie dabei auch Änderungen der Kollegen berücksichtigen.

Diesen menschenlesbaren Programmcode wandeln die OpenSuse-Entwickler durch Kompilieren in durch eine CPU ausführbaren Maschinencode um (Abbildung 1) und verpacken ihn in mit YaST oder Zypper installierbare Pakete. Alle modernen Programme setzen auf von Bibliotheken bereitgestellte Funktionen auf. Gewöhnlich nutzen unter Linux alle Anwendungen systemweit einheitliche Versionen dieser Libraries. Dass es sich dabei oft nicht um die Fassungen handelt, mit denen die Programmentwickler ihre Software testeten, sorgt für weiteres Problempotenzial.

Abbildung 1: Entwickler schreiben Programme in einer Programmiersprache wie C (links). Die Pakete einer Linux-Distribution dagegen enthalten Maschinencode (rechts), den die CPU ausführt.

Anlaufstellen

Typischerweise knirscht es also an zwei Stellen: Entweder entwickeln die Programmierer ihre Anwendung weiter und übersehen Auswirkungen, die eine Codeänderung an einer Stelle auf andere Bereiche hat. Oder das Einbinden eines Programms in die Systemumgebung sorgt für Probleme, die den Entwicklern entgingen, weil sie ihren Code in einer anderen Umgebung testeten.

Im ersten Fall sind die Entwickler des Programms selbst die richtige Anlaufstelle zum Melden des Bugs, im zweiten die Linux-Distributoren (siehe Kasten “Anlaufstellen für Fehlermeldungen”). Durchschnittsanwendern fällt es oft schwer, zu unterscheiden, welcher Fall vorliegt. Tritt ein Problem jedoch nach einem Einspielen eines Updates ein, des nicht das Programm selbst auffrischt, liegt es nahe, auf einen distributionsspezifischen Fehler zu tippen. Spielt das Update dagegen, insbesondere unter Tumbleweed, eine neue Programmversion ein, dann liegt wahrscheinlich ein Fehler in der Software selbst vor.

Möchten Sie Bugs direkt an die Entwickler eines bestimmten Programms reporten, genügt oft eine Internet-Suche nach “Programm bugs”, um den Bugtracker zu finden. In der Regel stellen lediglich größere Projekte einen eigenen Bugtracker zur Verfügung, kleinere nutzen oft einen Quellcode-Hosting-Dienst wie Github [1] oder Gitlab [2], die einen solchen mitliefern. Suchen Sie hier auf der Homepage des Programms oder per Internet-Suche zunächst nach dem Quellcode des Programms. Im Github- oder Gitlab-Projekt des Programms finden Sie dann unter dem Stichwort Issues (Probleme) an prominenter Stelle den gesuchten Meldekopf (Abbildung 2).

Abbildung 2: Quellcode-Hoster wie Gitlab und Github bieten den beherbergten Open-Source-Projekten auch gleich einen Bugtracker.

Sind Sie sich bezüglich der richtigen Anlaufstelle unsicher, beschreiben Sie den Fehler zunächst im OpenSuse-Forum [3] in der Rubrik Application oder Anwendungen und bitten dort um Hilfestellung für einen Bug Report. In der OpenSuse-Community gibt es ein deutsches Forum, andere Bugtracker erwarten Englisch als Sprache für Meldungen. Für Fehler in Systemkomponenten publizieren Sie in Rubriken wie Installation/Administration oder Hardware.

Im Zweifelsfall erweist sich der Bugtracker der Distribution als passende Anlaufstelle, um erst einmal abzuklären, ob es sich um ein OpenSuse-spezifisches Problem handelt. Meldet sich dort ein Entwickler und bittet Sie den Fehler “upstream” zu melden, dann verweist er Sie mit diesem Fachausdruck an die eigentlichen Entwickler des Programms.

Fehlerverwaltung

Bei Bugtrackern (Abbildung 3) handelt es sich um spezialisierte, entfernt an Webforen angelehnte Webanwendungen. Entwickler oder andere Anwender antworten wenn möglich auf Meldungen, zum Beispiel um nach weiteren Informationen zu fragen oder um die vorliegenden Fakten zu präzisieren. Jeder Bug Report durchläuft Phasen wie Confirmed (bestätigt – die Entwickler konnten den Bug nachvollziehen), Fixed (repariert – allerdings nicht zwangsläufig schon als stabile Version erschienen), Worksforme (bei mir geht’s – die Entwickler können den Fehler nicht nachvollziehen) oder Wontfix (werde ich nicht fixen – die Entwickler halten den Bug nicht für reparaturbedürftig). Eine Suchfunktion hilft dabei herauszufinden, ob andere den von Ihnen beobachteten Fehler bereits meldeten.

Abbildung 3: Ein Bugtracker wie hier der für Gimp im Gnome-Quellcode-Hosting-Dienst sammelt eingegangene Bug Reports, damit die Entwickler sie abarbeiten.

Den KDE-Bugtracker zum Beispiel erreichen Sie unter https://bugs.kde.org. KDE nutzt, wie viele andere Softwareprojekte, das Bugtracker-Urgestein Bugzilla [4]. Es lohnt sich daher, sich diese optisch sperrige, doch funktional exzellente Webanwendung näher anzusehen. Sie begegnen ihr, oft farblich an die Projekt-CI angepasst, bei vielen größeren Softwareprojekten.

Kleinere Teams, die auf Hosting-Dienste wie Github oder Gitlab setzen, nutzen die dort integrierten Bugtracker. Sie bieten moderner gestaltete Such-Interfaces. Bei Gitlab öffnet sich nach Aktivieren des Suchfelds ein Popup, das eine Suche nach einem bestimmten Label anbietet, zum Beispiel nach Bugs, also echten gemeldeten Fehlern, oder Enhancement, also Verbesserungsvorschlägen. Bei Github erreichen Sie diese Funktion über den gleichnamigen Button rechts vom Suchfeld. Schlagwörter dürfen Sie hier ebenfalls benutzen.

Abbildung 4 zeigt einen Bug Report für einen Fehler im KDE-Dateimanager Dolphin in Zusammenhang mit dem per [F4] einzublendenden Konsolenunterfenster. Wechseln Sie die Verzeichnisse in Dolphin per Tastatur-Shortcut, zum Beispiel per [Alt]+[Pfeil-nach-links] zum Blättern in der History der besuchten Ordner, so geht die Synchronisation zwischen dem Verzeichnis im Dateimanager und der Konsole verloren.

Abbildung 4: Ein Eintrag im KDE-Bugtracker beschreibt einen Fehler im Dateimanager Dolphin: Beim schnellen Wechsel von Verzeichnissen verliert das Konsolenunterfenster die Synchronisation mit dem Dateimanager.

Nehmen wir an, Sie finden einen solchen Fehler und möchten herausfinden, ob die Entwickler ihn bereits kennen. Als erste Anlaufstelle dient das Schnellsuchfeld im Bugtracker (Abbildung 5). Um den Fehler zu finden, könnten Sie dort “dolphin terminal in sync” eingeben.

Abbildung 5: Die Schnellsuche in Bugzilla, dem verbreitetsten Bugtracker, benutzen Sie, indem Sie wie bei einer Internet-Suchmaschine Suchbegriffe in das zentrale Eingabefeld auf der Startseite oder das auf allen Seiten sichtbare obere Feld mit dem Lupensymbol eingeben.

Eine trennschärfere Suche bietet der Link Search im Seitenkopf: Er öffnet ein zwar abschreckend komplex wirkendes Eingabeformular (Abbildung 6). In der Praxis genügt es aber, im Listenfeld Product das Programm dolphin auszuwählen und in das Feld Summary den Text einzutragen, den Sie in den Kommentaren finden möchten. Anders als die Schnellsuche stellt das sicher, dass die Suchergebnisse tatsächlich Dolphin betreffen und nicht bloß dieser Programmname in den Kommentaren vorkommt.

Abbildung 6: Die erweiterte Suche von Bugzilla wirkt komplex, doch dort Schlagworte aus der Summary mit der Suche nach einem Product (also einem bestimmten Programm) zu kombinieren, verbessert die Trefferquote gegenüber der Schnellsuche deutlich.

Es fällt naturgemäß schwer, per Schlagwortsuche auszuschließen, dass schon eine Meldung des von Ihnen gefundenen Bugs vorliegt. Bugtracker bringen daher eine Funktion mit, um doppelt gemeldete Bugs zusammenzufassen. Es stellt also kein größeres Problem dar, wenn mehrere Anwender denselben Fehler melden. Schlimmer wäre es, wenn die Entwickler weniger verbreiteter Programme gar keine Bug Reports erhalten: Viele Anwender wissen nicht, dass es relativ einfache Möglichkeiten gibt, einen Fehler zu melden, und dass die Entwickler sich über jeden Report freuen.

Faktenlage

Doch sehen wir uns zunächst den eigentlichen Bericht des Anwenders nyanpasu64 [5] aus Abbildung 4 an. Er kann als Beispiel für einen sinnvoll formulierten Bug Report herhalten, denn er nennt konkrete Schritte, wie sich der gemeldete Fehler reproduzieren lässt. Schließlich müssen die Entwickler den Bug erst einmal selbst beobachten, um ihn im Code aufspüren und beheben zu können. Bei jeder Fehlermeldung sollten Sie daher eindeutig nachvollziehbar Ihr Vorgehen beschreiben, als das Problem auftrat. War beim Arbeiten mit dem Programm eine Datei geöffnet, so hilft es, sie im Bugtracker als Attachment anzuhängen.

Vor Ihrem ersten Report legen Sie einen Account an. Dafür fordert der KDE-Bugtracker nach einem Klick auf New Account ganz rechts oben lediglich eine gültige E-Mail-Adresse. Dann rufen Sie über New oben links in der Kopfleiste das Formular zum Melden des Fehlers auf. Bereits voreingetragen sind die Zwischenüberschriften SUMMARY, STEPS TO REPRODUCE, OBSERVED RESULT und EXPECTED RESULT. Für die Entwickler ist es wichtig, dass Sie nicht nur Ihre Beobachtungen zum Fehler formulieren, sondern auch Ihre Erwartung, wie das Programm denn hätte funktionieren sollen – nur um sicherzugehen, dass kein Missverständnis vorliegt. Als unverzichtbar gilt auch die Information, ob der Fehler immer in der Form auftritt, oder nur gelegentlich.

Da Probleme potenziell nur in bestimmten Systemumgebungen auftreten, benötigen die Entwickler genaue Informationen zu Ihrem Linux-System. Als Basisinformation gelten der Name und die Version der Distribution. Aus beiden zusammen lassen sich die Versionen aller vom Programm genutzten Pakete ermitteln. In KDE-Anwendungen und manchen anderen Programmen finden Sie diese außerdem im Menü Hilfe unter Über <Programm> (Abbildung 7). Geben Sie diese Information zusätzlich zur Distributionsversion an, dann müssen die Empfänger nicht recherchieren, welche Versionen der grundlegenden Komponenten in Ihrem System vorliegen.

Abbildung 7: Der Eintrag Über Dolphin im Menü Hilfe nennt, wie bei vielen Anwendungen, die Programmversion und wichtiger die Bibliotheken.

Bei einer laufend aktualisierten Distribution wie OpenSuse Tumbleweed lässt sich keine Distributionsversion nennen. Hier sollten Sie vor einem Bug Report zunächst alle Updates einspielen und prüfen, ob der Fehler weiterbesteht. Der Kommandozeilenbefehl cat /etc/issue nennt Ihnen dann ein Release-Datum des eingespielten Updates, das Sie stets angeben sollten.

Bei einem funktionellen Bug müssen die Entwickler aus einer möglichst genauen Beschreibung der Fehlfunktion und Ihres Kontexts eruieren, wo der Fehler liegt: Was haben Sie im Programm gemacht, als es abstürzte? Wenn Sie damit eine Datei bearbeiten, erweist es sich als hilfreich, sie dem Bug Report hinzuzufügen. Auch die Informationen aus dem Dialog About im möglicherweise vorhandenen Hilfe-Menü hilft weiter. Bei Programmabstürzen gibt es jedoch darüber hinaus mit den sogenannten Backtraces (Abbildung 8) ein mächtiges Hilfsmittel: Sie dokumentieren die Stelle im Programmcode, die für den Absturz verantwortlich zeichnet.

Abbildung 8: Einige wenige Programme wie Gimp öffnen nach einem Absturz selbst ein Fenster mit einem Backtrace für einen Bug Report.

Nachverfolgung

Zu Beginn des Artikels gingen wir bereits darauf ein, dass die Entwickler menschenlesbaren Programmcode schreiben, auf dem Rechner des Anwenders jedoch für Menschen in der Praxis unverständlicher Maschinencode abläuft. Um aus der Stelle im Maschinencode, an der der Absturz erfolgt, auf die Stelle im Programmcode rückzuschließen, die den Fehler verursacht, steht in C- und C++-Programmen ein Debug Symbols genannter Link-Mechanismus zur Verfügung.

Die meisten Anwendungen basieren auf diesen beiden Programmiersprachen. Daher gibt es zu vielen OpenSuse-Programmpaketen ein Zusatzpaket mit dem Namensanhang -debuginfo, das die Debug-Symbole für das Grundpaket enthält. Um Platz zu sparen, installiert das System diese Pakete jedoch grundsätzlich nicht mit. Aussagekräftige Backtraces setzen die Debuginfo-Pakete für das Programm und alle beteiligten Bibliotheken jedoch voraus. Wenn Sie einige GByte zusätzlich belegter Plattenplatz nicht stört, ziehen Sie über den Menüpunkt Extras | Alle passenden debuginfo-Pakete installieren im YaST-Modul Software die Debug-Informationen aller installierten Pakete nach.

Es gibt aber auch ressourcenschonendere Lösungen. Am einfachsten gelingt das Erstellen von Backtraces unter KDE für KDE-Programme: Hier genügt es systemd-coredump zu installieren und das System neu zu starten. Stürzt anschließend unter KDE ein Programm ab, dann erscheint ein Popup namens Dr Konqui (Abbildung 9). Dabei handelt es sich um den Absturz-Handler von KDE, der die Optionen Probleme berichten und Anwendung neu starten anbietet. Verschwindet das Popup nach ein paar Sekunden, so lässt sich der Assistent KDE-Absturzbehandlung (Abbildung 10) immer noch durch einen Klick auf das Icon mit den nach unten weisenden Mundwinkeln in der Task-Leiste öffnen.

Abbildung 9: KDE bringt einen Assistenten mit, der nach Absturz eines KDE-Programms automatisch eine Absturzrückverfolgung (Backtrace) erstellt.

Abbildung 10: Die KDE-Absturzbehandlung automatisiert das Erstellen von Backtraces und sorgt für die hierfür erforderlichen Debuginfo-Pakete – hier unter OpenSuse Leap 15.3 per Installieren-Button, unter Tumbleweed sogar ganz ohne Benutzerinteraktion.

Der KDE-Crash-Assistent kümmert sich auch um die für taugliche Backtraces benötigten Debug-Informationen: Unter Tumbleweed startet der Assistent automatisch das Herunterladen von Debug-Daten. Unter Leap 15.3 erscheint im Crash-Handler der Button Debug-Symbole installieren. Ein Klick darauf öffnet ein Konsolenfenster, das nach Eingabe des Root-Passworts die benötigten Debuginfo-Pakete installiert.

Im Reiter Entwickler-Informationen der KDE-Absturzbehandlung finden Sie schließlich den Backtrace. Fügen Sie diese Absturzinformationen einem Bug Report an, dann erhöht das die Chance erheblich, dass sich die Entwickler des Fehlers annehmen. Dazu drücken Sie im Crash-Assistenten [Strg]+[A] und [Strg]+[C], um den Backtrace-Text in die Zwischenablage zu kopieren. Alternativ speichern Sie ihn per Klick auf das Diskettensymbol als Textdatei.

Handarbeit

Allerdings funktioniert der KDE-Crash-Assistent in OpenSuse nur unter KDE und für KDE-Programme. Entsprechende Informationen unter anderen Desktop-Umgebungen und für Nicht-KDE-Programme zu sammeln, gelingt nicht ohne Rückgriff auf die Konsole. Die hierfür nötigen Schritte lassen sich aber relativ einfach nachvollziehen.

Um einen Backtrace ohne die Unterstützung des KDE-Assistenten zu erstellen, müssen Sie unter Leap 15.3 Ihr Benutzerkonto zunächst den Gruppen systemd-coredump und systemd-journal hinzufügen und den Rechner neu starten. YaST bietet dafür das Modul Benutzer- und Gruppenverwaltung an (Abbildung 11). Unter Tumbleweed gibt es von Haus aus keine Rechteprobleme. Auf beiden OpenSuse-Spielarten muss allerdings das bereits erwähnte Paket systemd-coredump existieren.

Abbildung 11: Bearbeiten Sie unter Leap 15.3 im YaST-Modul Benutzer- und Gruppenverwaltung Ihr Benutzerkonto und aktivieren Sie im Reiter Details die Kontrollkästchen vor der Gruppenzugehörigkeit von systemd-coredump und systemd-journal.

Rufen Sie auf der Konsole nach einem Programmabsturz zunächst coredumpctl auf. Sie erhalten dann eine Liste aller Programmabstürze seit dem letzten Neustart. Achten Sie auf die Spalten PID und EXE. Die EXE-Spalte nennt die ausführbare Datei des abgestürzten Programms, anhand derer Sie erkennen, welche Zeile zum aktuellen Problem passt.

Führen Sie dann coredumpctl gdb PID aus, wobei Sie PID durch den Wert aus der gleichnamigen Spalte in der Ausgabe von Coredumpctl ersetzen. Beim Benutzen des GNU-Debuggers GDB [6] sollten Sie Geduld mitbringen: Oft dauert es eine ganze Weile, bis sich auf der Eingabeaufforderung etwas bewegt.

In aller Regel müssen Sie nun Debuginfo-Pakete installieren. Aktivieren Sie dazu zunächst im YaST-Modul Software alle Repositories mit dem Namensbestandteil -debug. Führen Sie dann den Zypper-Befehl in Meldungen wie Missing separate debuginfos, use: zypper install gimp-debuginfo-2.10.30-lp153.2.3.x86_64 aus. Damit GDB den Text vollständig anzeigt, drücken Sie [C]+[Eingabe].

Markieren Sie den ganzen zypper-install-Befehl bis zum letzten Namen der Debuginfo-Pakete und kopieren Sie ihn in die Zwischenablage, und zwar auf der Konsole ausnahmsweise mit [Strg]+[Umschalt]+[C]. Beenden Sie GDB mit [Q]+[Eingabe]. Öffnen Sie dann ein neues Konsolenfenster, loggen Sie sich dort mit su als Root ein, und fügen den Inhalt der Zwischenablage mit [Strg]+[Umschalt]+[V] ein. Ein Druck auf die Eingabetaste startet die Installation der benötigten Debug-Daten. Dann kehren Sie unter Leap zum ersten Konsolenfenster zurück (das Sie unter Tumbleweed gar nicht erst verlassen mussten), und starten dort GDB mit coredumpctl gdb PID neu.

An der GDB-Eingabeaufforderung tippen Sie nun bt full, um einen vollständigen Backtrace zu erzeugen (Abbildung 12). Der “magische” Backtrace-Text, der Programmierern bei der Fehlerfindung weiterhilft, erscheint nach [C]+[Eingabe] zwischen der Zeile --Type <RET> for more, q to quit, c to continue without paging--c und der GDB-Eingabeaufforderung. Markieren Sie den Abschnitt mit der Maus, kopieren Sie ihn via [Strg]+[Umschalt]+[C] in die Zwischenablage, und fügen Sie ihn dem Bug Report hinzu.

Abbildung 12: Mit etwas mehr Aufwand produziert GDB auf der Konsole dieselben Backtraces wie die KDE-Absturzbehandlung für KDE-Programme.

Fazit

Bugs zu melden kostet ein wenig Mühe, erfordert aber kein Fachwissen über Programmierung. Meist nennt die Homepage einer Software direkt den zugehörigen Bugtracker – schließlich wünschen sich die Entwickler dieses Feedback. Bei Hosting-Plattformen wie Github oder Gitlab liegt der Bugtracker ohnehin nur einen Klick entfernt. Das Melden von Bugs erfordert jedoch jeweils das Anlegen eines Benutzerkontos. Andererseits: Wer kostenlose Software nutzt, in die andere unzählige Stunden Arbeit investieren, beteiligt sich damit mit wenig Aufwand auch ohne eigene Programmierkenntnisse durch das Melden von Fehlern konstruktiv an der Entwicklung. (tle)