Was in einen Problem Report gehört

• Allgemeine Hinweise
• Eine Kernel Panic melden

Jede Datenbank ist lediglich so gut wie die Daten die in ihr enthalten sind. Generell diktiert gesunder Menschenverstand (die Existenz eines solchen vorausgesetzt) die Informationen die am hilfreichsten wären um ein Problem in der Software aufzuspüren und zu beheben.

Allgemeine Hinweise

• Umfassen Sie alles, was Sie wissen wollen würden, wenn Sie sich den Problem Report anschauen würden. Es ist nicht unbedingt notwendig, absolut jedes minuziöse Detail zu protokollieren; alles, was auf Ihrem System anders sein könnte als auf anderen, sollte jedoch notiert werden (z. B. der Wert der PATH Umgebungsvariablen).

• Darstellungen, sofern sie in einem begrenzten Rahmen sind, weisen sich oft als nützlich aus. Wenn z. B. eine Person, die für einen Programmfehler verantwortlich ist, erfährt, daß zuerst A, dann B und schliesslich C ausgeführt wurde, kann diese Person schlussfolgern, daß in dieser Reihenfolge evtl. ein Zwischenschritt ausgelassen wurde oder ein unerwartetes Ergebnis erzielte. Es sei jedoch nochmals betont, daß es wichtig ist, die Informationen auf die wesentlichen zu beschränken ("Ich habe das Programm gestartet und ging mir dann eine Tasse Kaffee holen (Kolumbianischer Kaffee, mit Milch und einem Päckchen Zucker), sprach am Telefon mit Sabine als plötzlich DIESES PROBLEM auftrat...").

• Richard Stallman schrieb (sinngemäß übersetzt):

  Ein Grundprinzip für die Berichterstattung eines Programmfehlers lautet: Erläutere alle Fakten. Wenn Sie nicht sicher sind ob eine bestimmte Tatsache erwähnt werden soll oder nicht, erwähnen Sie sie!

  Dies gilt für alle Problem Report Systeme, sowohl bezüglich Computer Software, Kriminalberichten oder Motorrad Reparaturen. In Bezug auf Software ist dies sogar noch wichtiger, da scheinbar unbedeutende Kleinigkeiten oft große Unterschiede machen können (z. B. die Umbenennung einer Variablen, ein fehlendes Semikolon usw.).

• Bitte nur ein Problem pro Problem Report. Wenn Sie mehrere Probleme haben, senden Sie bitte mehrere PRs. Dies führt zu einer besseren Kontrolle darüber, welches Problem mit welchem Programm assoziiert wird und gewährleistet eine einfachere Verfolgung des Problems.

• Es schadet nie, selber ein wenig nachzuforschen ob der von Ihnen gefundene Bug bereits gemeldet wurde. Viele Software Releases beinhalten eine Liste bekannter Programmfehler als Teil der Dokumentation. Des Weiteren ist es eine gute Idee, in der NetBSD GNATS Problem Report Datenbank zu suchen, um zu sehen ob noch jemand anders Ihr Problem bereits gemeldet hat (wer weiss, vielleicht hat ja sogar schon jemand eine Lösung gefunden!).

• Je mehr ein PR dem Standard-Format folgt, desto weniger Interaktion wird von Seiten des Datenbank Administrators benötigt um die Informationen in die korrekte Kategorie einzuordnen. Bitte bedenken Sie, daß alles, was menschliche Interaktion benötigt immer auch mehr Zeit in Anspruch nimmt; Zeit, die besser genutzt würde, um das Problem zu lösen. Daher ist es in jedermanns Interesse, daß die Informationen eines PRs so korrekt wie möglich (sowohl in Inhalt als auch in Form) sind. Bitte lesen Sie die Beschreibung der Formularfelder eines NetBSD Problem Reports .

Eine Kernel Panic melden

Nun gab es also eine kernel panic, Ihr Bildschirm (oder Log) ist voller Hexadezimal-Zahlen und Ihr System brach zusammen. Es ist wichtig, dieses Problem zu melden, da ein echtes Betriebssystem niemals zusammenbrechen sollte, es sei denn die Computer Hardware hat eine Fehlfunktion (ein BS kann leider nicht viel tun, um Hardware Fehler zu korrigieren). Daher bleiben lediglich Programmfehler in dem Betriebssystem-Kern (dem Kernel) übrig, und dies sind die Fehler die wir verfolgen und beheben müssen um NetBSD noch stabiler und robuster als es bereits ist, zu machen.

Das Problem dabei jedoch ist, daß der Stapelspeicherauszug (stack dump) den der Kernel ausdruckt ganz spezifisch für Ihr System ist und die Nummern wieder zurück in Referenzen der Symbol-Tabelle umgewandelt werden müssen, um es jemandem, der nicht den Kernel Ihres Systems nutzt, zu ermöglichen, einen genauen Eindruck zu bekommen, wo das System abbrach.

Am Allerwenigsten sollten Sie die "PC" Nummern notieren und sie in symbolische Referenzen umwandeln - dies ist der Program Counter des Computers, welcher anzeigt, welchen Code er gerade ausführte. Sollte es Ihnen möglich sein, so wäre es ideal, wenn Sie den gesamten Auszug kopieren und in den Problem Report einfügen könnten.

Wenn der Kernel nun also etwas wie folgt ausdruckt (normalerweise viele ähnliche Zeilen):

pc = 0xf80ff430 args = (0x0, 0x41001fe5, 0xf8139c00, 0xf8123d20, 0xf8101e38, 0xf8143800, 0xf8123c68) fp = 0xf8123c68

Die PC-Nummer ist spezifisch für Ihren Kernel und es ist unwahrscheinlich, daß er mit dem eines anderen Kernels gleich ist. Daher muss er in eine symbolische Referenz umgewandelt werden. Um den Hexadezimalwert des PC in eine symbolische Referenz umzuwandeln, sollten Sie gdb(1) wie folgt verwenden:

	gdb -k /netbsd
	x 0xf80ff430

	0xf80ff430 <cpu_reboot+196>:     0x40000093

Den "<cpureboot+196>" Teil von gdb(1) ist genau der Teil, denn die Leute, die an Ihrem Problem Report arbeiten werden. benötigen. Bitte notieren Sie diesen Teil (idealerweise zusammen mit dem Rest der "args" Zeile) in Ihrem Problem Report.

Problem Report #3765 ist ein gutes Beispiel eines ausführlichen PR einer kernel panic.

Home Page