# Wie Fehler (Bugs) berichtet werden

Gute Fehlerberichte sind ein sehr wertvoller Beitrag zur Entwicklung jedes Softwareprojekts. Aber genau wie das Schreiben guter Software benötigt das Anfertigen von Berichten über Probleme etwas Arbeit. Bitte sei dir darüber im klaren, dass die meisten Entwickler sehr beschäftigt sind und eine unverschämt hohe Anzahl Mails bekommen. Verstehe daher, dass du, obwohl dein Feedback für die Verbesserung von MPlayer sehr wichtig ist und geschätzt wird, alle Informationen, die wir fordern, zur Verfügung stellen und die Anweisungen dieses Dokuments strikt befolgen musst.

## Berichte sicherheitsrelevante Fehler

Im Falle, dass du einen Exploit-fähigen Fehler gefunden hast und gern das richtige tun möchtest und uns diesen beseitigen lässt, bevor du ihn veröffentlichst, würden wir uns freuen, deinen Rat zur Sicherheit unter security@mplayerhq.hu zu erhalten. Füge dem Betreff bitte [SECURITY] oder [ADVISORY] hinzu. Stelle bitte sicher, dass dein Bericht eine vollständige und detaillierte Analyse des Fehlers enthält. Einsendung einer Lösung wird sehr dankend angenommen. Bitte verzögere deinen Bericht nicht, um einen Proof-of-concept-Exploit zu schreiben, den kannst du in einer weiteren Mail schicken.

## Wie Fehler beseitigt werden

Wenn du das Gefühl hast, dass du die nötigen Kenntnisse hast, bist du dazu eingeladen, dich selbst an der Lösung des Fehlers zu versuchen. Vielleicht hast du das schon? Bitte lies dieses kurze Dokument, um herauszufinden, wie dein Code Teil von MPlayer werden kann. Die Leute der Mailing-Liste MPlayer-dev-eng werden dir zur Seite stehen, wenn du Fragen hast.

## Wie Regressionstests mit Subversion durchgeführt werden

Ein Problem, das manchmal auftreten kann ist "es hat vorher funktioniert, jetzt nicht mehr...". Hier ist eine Schritt-für-Schritt-Prozedur, um herauszufinden, wann das Problem aufgetreten ist. Dies ist nicht für gelegentliche Benutzer.

Zuerst musst du dir MPlayers Sourcenverzeichnis aus dem Subversion-Repository besorgen. Eine Anleitung hierzu kann unten auf dieser Seite gefunden werden.

Du wirst dann im mplayer/-Verzeichnis ein Abbild des Subversion-Baums auf der Client-Seite haben. Führe jetzt ein Update für dieses Abbild durch auf das Datum, das du möchtest:

    cd mplayer/
    svn update -r {"2004-08-23"}

Das Datumsformat ist YYYY-MM-DD HH:MM:SS. Die Benutzung des Datumsformats stellt sicher, dass du in der Lage sein wirst, Patches anhand des Datums, an dem sie eingespielt wurden, extrahieren kannst, wie im MPlayer-cvslog-Archiv.

Gehe nun vor wie bei einem normalen Update:

    ./configure
    make

Falls ein Nicht-Programmierer dies liest: Der schnellste Weg, an den Punkt zu gelangen, wo das Problem auftrat ist eine Binärsuche — das bedeutet: Suche das Datum der Bruchstelle, indem du das Suchintervall wiederholt halbierst. Zum Beispiel, wenn das Problem 2003 auftrat, starte in der Mitte des Jahres und frage "Ist das Problem schon da?". Wenn ja, gehe zurück zum 1. April; wenn nicht, gehe zum 1. Oktober und so weiter.

Wenn du viel Festplattenspeicher frei hast (eine vollständige Compilierung benötigt momentan 100 MB, und ungefähr 300-350 MB, wenn Debugging-Symbole mit dabei sind), kopiere vor einem Update die älteste Version, von der bekannt ist, dass sie funktioniert; das spart Zeit, wenn du zurückgehen musst. (Es ist normalerweise nicht nötig, 'make distclean' vor einer erneuten Compilierung einer früheren Version auszuführen. Wenn du also keine Backup-Kopie deines Original-Sourcebaums machst, wirst du alles neu compilieren müssen, wenn du beim gegenwärtigen wieder angekommen bist.)

Wenn du den Tag gefunden hast, an dem das Problem auftrat, fahre mit der Suche mit dem mplayer-cvslog-Archiv (sortiert nach Datum) und einem genaueren svn update, welches Stunde, Minute und Sekunde beinhaltet, fort:

    svn update -r {"2004-08-23 15:17:25"}

Dies wird dir erlauben, den genauen verursachenden Patch leicht zu finden.

Wenn du den Patch gefunden hast, der Ursache des Problems ist, hast du fast gewonnen; Berichte darüber im MPlayer Bugzilla-System oder melde dich bei MPlayer-users an schicke es dort ein. Es gibt eine Chance, dass der Autor einspringt und eine Lösung vorschlägt. Du kannst auch einen genauen Blick auf den Patch werden, bis er genötigt ist, zu offenbaren, wo der Fehler ist :-).

## Wie Fehler berichtet werden

Probiere vor allem zu allererst die letzte Subversion-Version von MPlayer, da dein Problem dort möglicherweise schon behoben ist. Die Entwicklung geht extrem schnell voran, die meisten Probleme in offiziellen Versionen werden innerhalb von Tagen oder sogar Stunden den Entwicklern mitgeteilt. Benutze daher bitte nur Subversion beim Berichten von Fehlern. Dies gilt auch für Binärpakete von MPlayer. Subversion-Anweisungen findest du am unteren Ende dieser Seite oder in der README. Wenn dies nicht hilft, ziehe die Liste bekannter Fehler und den Rest der Dokumentation zurate. Wenn dein Problem nicht bekannt ist oder durch unsere Anweisungen nicht gelöst werden kann, dann teile uns den Fehler mit.

Sende bitte keine Fehlerberichte privat an individuelle Entwickler. MPlayer ist Gemeinschaftsarbeit, also wird es vielleicht mehrere interessierte Leute geben. Es kommt auch teilweise vor, dass derselbe Fehler von anderen Benutzern gefunden wurde, die bereits eine Lösung zur Umgehung des Problems haben, auch wenn es sich um einen Fehler im MPlayer-Code handelt.

Bitte beschreibe dein Problem so detailliert wie möglich. Dazu gehört ein klein wenig Detektivarbeit, um die Umstände einzuengen, unter denen das Problem auftritt. Tritt der Fehler nur in bestimmten Situationen auf? Ist er abhängig von Dateien oder Dateitypen? Tritt er nur bei einem Codec auf oder ist er davon unabhängig? Kannst du den Fehler mit allen Ausgabetreibern reproduzieren? Je mehr Informationen du zur Verfügung stellst, desto besser sind die Chancen, dass das Problem gelöst wird. Bitte vergiss nicht, auch die unten angeforderten wertvollen Informationen miteinzubeziehen. Ansonsten sind wir vermutlich nicht in der Lage, das Problem genau zu untersuchen.

Ein exzellenter und gut geschriebener Führer, wie Fragen in öffentlichen Foren gestellt werden sollen, ist How To Ask Questions The Smart Way von Eric S. Raymond. Es gibt noch einen mit dem Namen How to Report Bugs Effectively von Simon Tatham. Wenn du diese Richtlinien befolgst, solltest du Hilfe bekommen können. Bitte verstehe aber, dass wir alle den Mailinglisten freiwillig in unserer Freizeit folgen. Wir sind sehr beschäftigt und können nicht garantieren, dass du eine Lösung oder auch nur eine Antwort zu deinem Problem erhältst.

## Wo Fehler berichtet werden sollen

Melde dich bei der Mailingliste MPlayer-users an: und sende deinen Fehlerbericht an , wo dieser diskutiert werden kann.

Wenn du es bevorzugst, kannst du statt dessen auch unseren brandneuen Bugzilla verwenden.

Die Sprache der Liste ist Englisch. Bitte befolge die Standard- Netiquette-Richtlinien und sende keine HTML-Mails an eine unserer Mailinglisten. Du wirst ignoriert oder ausgeschlossen werden. Wenn du nicht weißt, was eine HTML-Mail ist oder warum sie böse ist, lies dieses feine Dokument. Es erklärt alle Details und beinhaltet Instruktionen, wie man HTML abschalten kann. Beachte auch, dass wir keine Kopien (CC, carbon-copy) verschicken. Es ist daher eine gute Sache, sich anzumelden, um auch wirklich deine Antwort zu erhalten.

## Was berichtet werden soll

Du wirst wahrscheinlich Logdateien, Konfigurationsinformationen und Beispieldateien in deinen Fehlerbericht aufnehmen müssen. Wenn einige von ihnen ziemlich groß werden, ist es besser, wenn du sie auf unseren FTP-Server hochlädst, und zwar in komprimierter Form (gzip und bzip2 bevorzugt). Gib dann in deinem Fehlerbericht nur den Pfad- und den Dateinamen an. Unsere Mailinglisten haben ein Nachrichten-Größenlimit von 80k, wenn du etwas größeres hast, musst du es komprimieren und hochladen.

### Systeminformationen

- Deine Linuxdistribution, Betriebssystem und Version, z.B.:

  - Red Hat 7.1

  - Slackware 7.0 + Entwicklerpakete von 7.1 ...

- Kernelversion:

      uname -a

- libc-Version:

      ls -l /lib/libc[.-]*

- gcc- und ld-Versionen:

      gcc -v
      ld -v

- binutils-Version:

      as --version

- Wenn du Probleme mit dem Vollbildmodus hast:

  - Window-Manager-Typ und Version

- Wenn du Probleme mit XVIDIX hast:

  - Farbtiefe von X:

        xdpyinfo | grep "depth of root"

- Wenn nur die GUI fehlerhaft ist:

  - GTK-Version

  - GLIB-Version

  - libpng-Version

  - GUI-Situation, in der der Fehler auftritt

### Hardware und Treiber

- CPU-Info (funktioniert nur unter Linux):

      cat /proc/cpuinfo

- Videokartenhersteller und Modell, z.B.:

  - ASUS V3800U chip: nVidia TNT2 Ultra pro 32MB SDRAM

  - Matrox G400 DH 32MB SGRAM

- Videotreibertyp & -version, .z.B.:

  - eingebauter Treiber von X

  - nVidia 0.9.623

  - Utah-GLX CVS 2001-02-17

  - DRI von X 4.0.3

- Soundkartentyp & -treiber, z.B.:

  - Creative SBLive! Gold mit OSS-Treiber von oss.creative.com

  - Creative SB16 mit Kernel-OSS-Treibern

  - GUS PnP mit OSS-Emulation von ALSA

- Füge bei Linuxsystemen im Zweifel die Ausgabe von `lspci -vv` bei.

### Configure-Probleme

Wenn du Fehlermeldungen beim Aufruf von `./configure` bekommst oder die automatische Erkennung von etwas fehlschlägt, so lies `configure.log`. Du könntest dort die Antwort finden, zum Beispiel mehrere Versionen derselben Bibliothek, die gemischt auf deinem System vorliegen, oder du hast vergessen, das Entwicklerpaket (die mit dem Suffix -dev) zu installieren. Wenn du denkst, dass es sich um einen Fehler handelt, binde `configure.log` in deinen Fehlerbericht ein.

### Compilierungsprobleme

Bitte füge diese Dateien an:

- config.h

- config.mak

Nur wenn die Compilierung unter einem dieser Verzeichnisse fehlschlägt, füge die folgenden Dateien an:

- Gui/config.mak

- libvo/config.mak

- libao2/config.mak

### Wiedergabeprobleme

Bitte füge die Ausgabe von MPlayer im ausführlichen Modus bei Level 1 an, denke aber daran, die Ausgabe nicht zu kürzen, wenn du sie in deine Mail einfügst. Die Entwickler benötigen alle Ausgaben, um das Problem angemessen zu untersuchen. Du kannst die Ausgabe folgendermaßen in eine Datei ausgeben:

    mplayer -v Optionen Dateiname > mplayer.log 2>&1

Wenn dein Problem speziell mit einer oder mehreren Dateien zu tun hat, lade diese bitte hoch nach:

Lade bitte auch eine kleine Textdatei hoch, die denselben Basisnamen wie deine Datei hat, mit der Erweiterung .txt. Beschreibe dort das Problem, das du mit dieser speziellen Datei hast und gib sowohl deine Emailadresse als auch die Ausgabe von MPlayer im ausführlichen Modus bei Level 1 an. Normalerweise reichen die ersten 1-5 MB einer Datei aus, um das Problem zu reproduzieren. Um ganz sicher zu gehen, bitten wir dich, folgendes zu tun:

    dd if=deinedatei of=kleinedatei bs=1024k count=5

Dies wird die ersten fünf Megabyte von 'deine-datei' nehmen und nach 'kleine-datei' schreiben. Probiere es dann erneut mit dieser kleinen Datei, und wenn der Fehler noch immer auftritt, ist dieses Beispiel für uns ausreichend. Bitte sende niemals solche Dateien via Mail! Lade sie hoch und schicke nur den Pfad/Dateinamen der Datei auf dem FTP-Server. Wenn die Datei im Netz verfügbar ist, reicht es, die exakte URL zu schicken.

### Abstürze

Du musst MPlayer in `gdb` aufrufen und uns die komplette Ausgabe schicken, oder, wenn du ein `core`-Dump des Absturzes hast, kannst du nützliche Informationen von der Core-Datei extrahieren, und zwar folgendermaßen:

#### Wie man Informationen eines reproduzierbaren Absturzes erhält

Compiliere MPlayer neu mit Debugging-Code aktiviert:

    ./configure --enable-debug=3
    make

und rufe dann MPlayer innerhalb gdb auf mit:

    gdb ./mplayer

Du befindest dich nun innerhalb gdb. Gib ein:

    run -v Optionen-an-mplayer Dateiname

und reproduziere den Absturz. Sobald du das getan hast, wird gdb zur Eingabeaufforderung zurückkehren, wo du folgendes eingeben musst:

    bt
    disass $pc-32 $pc+32
    info all-registers

#### Wie man aussagekräftige Informationen von einem Core-Dump extrahiert

Erzeuge die folgende Kommando-Datei:

    bt
    disass $pc-32 $pc+32
    info all-registers

Führe dann einfach folgendes Kommando aus:

    gdb mplayer --core=core -batch --command=Kommando_Datei > mplayer.bug

## Ich weiß, was ich tue...

Wenn du einen Fehlerbericht wie oben beschrieben geschrieben hast und du dir sicher bist, dass es ein Bug in MPlayer und nicht ein Problem mit dem Compiler oder eine defekte Datei ist, du die Dokumentation gelesen hast und keine Lösungen finden konntest und deine Soundtreiber OK sind, dann kannst du auch der mplayer-advusers-Mailingliste beitreten und dort deine Fehlerberichte einsenden. Du wirst dort schnellere und besser Antworten erhalten.

Aber sei gewarnt: Wenn du Anfängerfragen oder Fragen stellst, die in dieser Anleitung bereits beantwortet werden, wirst du ignoriert oder angemeckert, anstatt eine Antwort zu erhalten. Also ärgere uns nicht und trete der -advusers-Liste nur bei, wenn du weißt, was du machst und du dich für einen erfahrenen MPlayer-Benutzer oder -Entwickler hältst. Wenn du diese Kriterien erfüllst, sollte es kein Problem für dich sein, dich anzumelden...