Index
Zugang zu Trac
Bugreport erstellen
Bugs in Anwendungen
Bugs in Servern
Bugs im Kernel
Kernel Debugging Land - KDL
Syslog
Debug Ausgabe auf dem Bildschirm
Bugs von Hardware/Treiber
Bug gemeldet, und dann?

Bugs melden

Da es für die Haiku-Entwickler unmöglich ist, jede denkbare Hardware-Kombination oder jede mögliche Anwendungsweise eines Programms zu testen, ist es eine große Hilfe, wenn Fehler gemeldet werden. Da Haiku noch recht jung ist, sind Bugs nicht Ungewöhnliches. Nur mit Hilfe der Anwender können wir Haiku gemeinsam Stück für Stück perfektionieren.

Damit unser "Bugtracker" - also die Liste aller gefundenen Fehler - effektiv funktioniert, ist eine grundlegende Bug Tracker Etiquette zu wahren.

index Zugang zu Trac

Um ein Fehler-Ticket aufzugeben, muss man registrierter Benutzer beim Bugtracker sein.
Um sich anzumelden ist eine gültige E-Mail Adresse notwendig. Sollte nach dem Anmelden keine Bestätigungsmail ankommen, sollte man mal seinen Spam-Ordner überprüfen.

index Bugreport erstellen

Bevor man einen Fehler meldet, sollte man sich sicher sein, dass das nicht schon geschehen ist. Hierzu kann auch die Suchfunktion verwendet werden.
Nach dieser Überprüfung sollte man so genau wie möglich den Fehler beschreiben:

index Bugs in Anwendungen

Stürzt eine Anwendung ab, sollte man den Debugger aus dem erscheinenden Hinweisfenster aufrufen. Dadurch wird ein Terminal mit gdb (dem GNU Debugger) geöffnet. Gibt man dort bt ein, wird ein sogenannter "backtrace" erstellt, der komplett (auch mit dem Teil bevor bt eingegeben wurde) mit an die Fehlermeldung angehängt werden sollte.

index Bugs in Servern

Stürzen lebenswichtige Server wie der App Server, der Registrar oder der Input Server ab, bekommt man nicht den gewöhnlichen Crash-Hinweis zu sehen. Stattdessen wird der gesamte Bildschirm weiß und der gdb wird gestartet, der seine Ausgabe direkt auf den Bildschirm schreibt. Unter Umständen kann man immer noch die Maus bewegen, die daraufhin das Weiß und die gdb Ausgabe übermalt. Noch laufende Anwendungen, wie ProcessController oder die Uhr in der Deskbar, tun das vielleicht auch noch.
Außer dass alles etwas unansehnlicher und unbequemer ist, gilt eigentlich das gleiche wie für Bugs in Anwendungen. Am wichtigsten ist das sichern eines "backtrace" mittels bt. Weil man den Text ja nicht mehr irgendwohin kopieren kann, müsste man die Ausgabe per Kamera festhalten.

index Bugs im Kernel

Fehler im Kernel haben normalerweise die schwersten Auswirkungen und sind zugleich am schwierigsten zu debuggen. Es gibt unterschiedliche Symptome, die auf ein Problem von Kernel oder Treiber hindeuten:

Während nur der letzte Punkt explizit auf eine Hardware-Ursache eingeht, können auch alle anderen Symptome auf Fehler in einem Hardware Treiber hindeuten. Hat man einen Verdacht welche Hardware oder entsprechender Treiber mit dem Problem zu tun haben könnte, sollte man prüfen ob das Entfernen oder Deaktivieren von Hardware oder Treiber Abhilfe schafft. Wenn man das Problem beispielsweise beim WLAN vermutet, könnte diese Funktion vielleicht im BIOS ausgeschaltet werden. Wenn nicht, kann man auch den entsprechenden Treiber aus dem System entfernen (in /boot/System/add-ons/kernel/drivers/bin).

index Kernel Debugging Land - KDL

Stürzt das System nicht von selbst ins KDL, kann man das auch absichtlich mit der Tastenkombination ALTSysReqD erreichen.
Im KDL kann es passieren, dass die Tastatur nicht mehr funktioniert. PS/2 Tastaturen gehen immer, USB Tastaturen an UHCI Controllern nur wenn man vorher schonmal per Tastenkombination das KDL betreten hat. USB OHCI wird zur Zeit noch gar nicht unterstützt.

Das KDL ist eine Art Konsole. Es lassen sich Befehle eingeben, die Informationen über das System ausgeben. Folgende Befehle sind von besonderen Interesse:

bt (auch "sc") Zeigt einen "backtrace" wo genau der Fehler aufgetreten ist. Ist das System von selbst ins KDL gefallen, sollte man diesen Befehl unbedingt ausführen.
ints Zeigt die unbenutzten und verwendeten Interrupts.
co (auch "continue") Verlässt den Kernel Debugger und das System läuft - soweit möglich - normal weiter.
reboot Führt einen unmittelbaren Neustart durch. Alle ungespeicherten Daten gehen verloren und selbst was man gespeichert hat, aber noch nicht auf die Platte geschrieben wurde, ist weg.

Weitere Infos gibt es im Artikel Welcome to Kernel Debugging Land (Englisch).

Die Ausgaben im KDL werden zum seriellen Port geschickt (falls man einen hat und ein entsprechendes Nullmodemkabel samt zweiten Rechner, kann man die Ausgaben in einem Terminalprogramm aufnehmen). Außerdem werden sie ins Syslog geschrieben. Wenn man das KDL allerdings nicht verlassen kann, wird auch nichts ins Syslog geschrieben. Es gibt aber eine Bootloader Debug Option, die das trotzdem möglich macht (siehe weiter unten).

Von Ausgaben im KDL lassen sich auch QR-Codes erzeugen, die dann mit einem Smartphone oder ähnlichem zu Text konvertiert werden können. Der Blogpost QR Encode your KDL Output (Englisch) erklärt wie man mit diesem Feature Daten aus dem Kernel Debugging Land herausbekommt.

index Syslog

Dies ist die beste Methode Informationen über ein nicht-bootendes System zu gewinnen.
Das Syslog (kurz für System Log) enthält wertvolle Infos was im System abläuft, einschließlich der Ausgaben einer KDL Sitzung. Man sollte es immer an einen Trac Ticket hängen wenn es etwas mit dem Kernel zu tun haben könnte. Das Syslog befindet sich in der Datei /boot/Allgemein/var/log/syslog. Um in eine Datei schreiben zu können, braucht man ein funktionierendes System. Tritt ein Problem im Kernel auf (insbesondere bei spontanen Neustarts und nicht-fortsetzbaren KDL Sitzungen), kann es daher passieren dass es die letzten Ausgaben nicht mehr ins Syslog schaffen.

Durch die Option Enable debug syslog im Debug menu des Bootloaders wird das Syslog im Speicher etwas langlebiger. Das ist standardmäßig aktiviert. "Etwas langlebiger" bedeutet, dass es einen Reset überlebt und direkt danach noch im Bootloader verfübar ist. Bootet man allerdings ein Betriebssystem (zumindest bei Haiku, wahrscheinlich aber bei allen), werden diese Informationen zerstört. Man muss beim Neustart also unbedingt das Bootloader Menü mittels gedrückter SHIFT Taste aufrufen.
Dort sollte man im Debug menu jetzt die Einträge Display syslog from previous session und Save syslog from previous session sehen. Ersterer zeigt das Syslog direkt auf dem Bildschirm an, mit letzterem lässt es sich speichern. Momentan geht das nur auf FAT32 formatierten Medien. Möchte man dafür einen USB-Stick benutzen, den man allerdings erst zu spät reingesteckt hat und der deswegen nicht erkannt wurde, kann man den Rechner nochmals resetten und das Bootloader Menü erneut aufrufen. Es gilt aber immer noch: Bootet man ausversehen ein Betriebssystem, sind die Syslog Daten weg.

index Debug Ausgabe auf den Bildschirm

Die Ausgabe auf dem Bildschirm ist nur bei ganz bestimmten Situationen sinnvoll und hat bekanntermaßen Timing-Probleme. Es sollte also wirklich nur im Notfall benutzt werden.
Das ist zum Beispiel der Fall wenn Haiku nicht ganz hochfährt und Bootloader's Debug syslog option irgendwie nicht funktioniert. Noch bevor das Haiku Bootlogo erscheint, die SHIFT Taste gedrückt halten, um das Bootloader Menü aufzurufen. Von hier in das Menü Select safe mode options wechseln und dort weiter unten [ ] Enable on screen debug output aktivieren. (Die anderen Optionen kann man auch mal probieren, um zu versuchen Haiku erfolgreich zu booten. Wenn Haiku nur mit einer oder mehreren aktivierten Optionen hochfahren kann, sollte man natürlich erwähnen welche das sind.)
Abschließend geht man auf Return to main menu und dann Continue booting.
Auf dem Bildschirm werden einige Seiten Text ausgegeben, von denen aber nur die letzten paar für einen Bugreport interessant sind. Der Userguide hat noch weitere Infos zum Boot Loader.

index Bugs von Hardware/Treiber

Wenn ein Fehler gemeldet wird, der Hardware oder Treiber betrifft, sollten folgende Informationen als Textdateien an den Fehlerbericht angehängt werden:

- listdev Eine detaillierte Auflistung aller vorhandener Hardware inklusive "vendor id" und "pci id"; ähnlich den Befehlen lshw und lspci unter Linux.
- listusb -v Bei Fehlern im Zusammenhang mit USB, ähnlich dem Befehlt lsusb unter Linux.
- open /var/log/syslog Die zentrale Log-Datei von Haiku. Mit dem Befehl open kann das Log im Texteditor auf eine sinnvolle Länge gekürzt werden.
- listimage | grep drivers/ Eine Auflistung aller verwendeten Treiber.
- ints Nur im Kernel Debugging Land (siehe weiter oben). Es zeigt eine Liste aller verwendeter "Interrupts". Wenn sich mehrere Geräte zuviele von ihnen teilen, ist das schlecht.
- "On screen debug output" (die Bootloader Debug Option zur Ausgabe auf dem Bildschirm).

Die ersten vier dieser Befehle sind im Terminal einzugeben. Mit dem Zusatz " > output.txt" an den Befehl wird dessen Ausgabe in die Datei "output.txt" gespeichert, die dann an den Fehlerbericht angehängt werden kann.

index

Nachdem ein Fehler gemeldet wurde, wird sich ein Entwickler ihm annehmen und bewerten. Da es sich bei allen Entwicklern um Freiwillige handelt, die in ihrer Freizeit programmieren, kann es durchaus etwas dauern, bis man eine Rückmeldung erhält. Je mehr Informationen man einer Fehlermeldung beifügt oder nachreicht, um so leichter ist es für den Programmierer, diesen zu beheben.

Wenn man einen Fehler gemeldet hat ist es damit nicht abgeschlossen, eigentlich ist es erst der Anfang und man wird Teil des Entwicklungs-Prozesses von Haiku. Es ist durchaus möglich und eigentlich auch zu erwarten, dass sich ein Entwickler meldet, um näheres zu den Umständen des Fehler-Reports zu erfahren. Hier gilt wieder: je mehr man dem Entwickler helfen kann, um so leichter tut er sich mit der Fehlerbehebung. Erst wenn der Fehler als 'fixed' - also behoben - markiert ist, kann man sich zurücklehnen, mit dem guten Gefühl etwas beigetragen zu haben.