Absturzberichte

Wenn Mister Download Manager unerwartet geschlossen wird oder nicht mehr reagiert, öffnet sich ein Fenster für den Absturzbericht. Es zeigt, was passiert ist, lässt Sie den gesamten Bericht lesen und kann ihn an die Entwickler auf GitHub senden. Jeder Bericht hilft, das Problem für alle zu beheben.

Was Sie sehen

• Mister Download Manager wurde unerwartet geschlossen: MDM ist abgestürzt oder auf einen internen Fehler gestoßen und wurde geschlossen.
• Mister Download Manager reagiert nicht mehr: Das Fenster hat 8 Sekunden lang nicht geantwortet. MDM läuft noch, ist aber eingefroren. MDM beenden und neu starten schließt die eingefrorene Kopie und startet eine neue. Wenn MDM von selbst wieder antwortet, wird dies im Fenster angezeigt.

Im Fenster:

1. Was haben Sie getan, als es passierte? ist optional. Ein paar Worte, wie „Ich habe URL hinzufügen geöffnet“, helfen sehr.
2. Der Bericht zeigt alles, was gesendet werden würde. Lesen Sie ihn zuerst, wenn Sie möchten.
3. Auf GitHub senden öffnet das GitHub-Formular Crash report in Ihrem Browser, bereits ausgefüllt, zusammen mit dem Ordner, der den Bericht enthält. Ziehen Sie die Berichtsdatei in das Formular, überprüfen Sie sie und senden Sie sie ab. Sie benötigen ein GitHub-Konto. Es wird nichts von selbst gesendet.
4. Wenn jemand das gleiche Problem bereits gemeldet hat, wird dies im Fenster angezeigt (Bereits gemeldet als Problem #…). Gemeldetes Problem öffnen öffnet es und legt Ihren Bericht in die Zwischenablage, sodass Sie ihn als Kommentar hinzufügen können.

Die anderen Schaltflächen kopieren den Bericht, öffnen seinen Ordner oder starten MDM erneut.

Was ein Bericht enthält

• Was passiert ist: der Fehler und die Stelle im MDM-Code, an der er aufgetreten ist.
• Der Stack: die Stelle im MDM-Code, an der es abgestürzt oder eingefroren ist, und was jeder andere Teil davon getan hat.
• MDMs aktuelles Protokoll: zum Beispiel „Befehl AddUrl“ oder „Fenster geöffnet: add-url“.
• Das System: MDMs Version und wie Sie es installiert haben, Ihr Betriebssystem und dessen Version, der Prozessor, die Sprache und das Thema sowie die Anzahl Ihrer Downloads und Warteschlangen. Dies sind nur Zählungen.

Es enthält nicht:

• Ihre Download-Adressen oder Dateinamen;
• Ihren Benutzernamen, der in Ordnerpfaden als ~ angezeigt wird.

Wenn eine Fehlermeldung etwas zitiert, das Sie eingegeben haben, ist dieser Text im Bericht enthalten. Lesen Sie ihn daher vor dem Senden.

Die Absturzdatendatei (.dmp) ist eine Momentaufnahme dessen, was MDM zu diesem Zeitpunkt ausgeführt hat. Sie hilft den Entwicklern am meisten, kann aber Teile dessen enthalten, was MDM im Speicher hatte, wie z. B. Download-Adressen. Sie wird nur angehängt, wenn Sie Auch die Absturzdaten anhängen ankreuzen.

Wo Berichte gespeichert werden

Im Datenordner von MDM:

• crashes\: jeder Bericht (.txt) und seine Absturzdaten (.dmp);
• logs\: MDMs Protokoll (mdm.log, mit älteren als mdm.1.log und so weiter, jeweils 2 MB).

MDMs Datenordner ist %APPDATA%\misterdownloadmanager unter Windows, ~/Library/Application Support/misterdownloadmanager unter macOS und ~/.local/share/misterdownloadmanager unter Linux. Im portablen Modus ist es der Ordner data neben dem Programm.

Das Protokoll zeichnet auf, was MDM tut, sodass ein Bericht zeigen kann, was zu einem Problem geführt hat. Um mehr Details zu protokollieren, starten Sie MDM mit der Umgebungsvariablen MDM_LOG=debug.

Für Entwickler

So funktioniert es: Eine zweite Kopie von MDM, der Monitor, startet daneben mit --crash-monitor. Der Absturzcode befindet sich in crates/crash und crates/app/src/crash.rs.

• Probleme abfangen. Wenn MDM abstürzt (eine Windows-Ausnahme, ein Signal unter Linux, eine Mach-Ausnahme unter macOS), Panik bekommt oder einfriert, fordert es vom Monitor einen Dump an. Ein Einfrieren ist ein Fensterrahmen, der länger als 8 Sekunden läuft, beobachtet von einem Watchdog-Thread, der die im Ruhezustand verbrachte Zeit ignoriert. Der Monitor schreibt dann einen Minidump jedes Threads von außen, über minidumper und crash-handler. Ein abgestürzter Prozess schreibt niemals seinen eigenen Dump, was auch bei Firefox, Crashpad und Sentry so gehandhabt wird.
• Den Dump lesen. Der Monitor liest den Dump mit Mozillas rust-minidump. Er verwendet die Breakpad-Symbole der Version, wenn diese gefunden werden, oder die nativen Debug-Informationen neben einem Build aus dem Quellcode. Die Signatur des Berichts (zum Beispiel freeze in misterdownloadmanager::winui::combo_edit) bleibt bei Berichten über dasselbe Problem gleich, und das Fenster durchsucht bestehende Probleme danach.
• Symbole. Release-Builds enthalten Zeilentabellen (debug = "line-tables-only"), aber kein Download enthält die Debug-Informationen. CI wandelt sie in MisterDownloadManager-<version>-symbols-<platform>.zip (tools/installer/symbols.py, unter Verwendung von Mozillas dump_syms) um, die neben den anderen Dateien der Version veröffentlicht werden. Das Berichtsfenster ruft die Zip-Datei für seine eigene Version ab, wenn ein Stack nur Adressen anzeigt.
• Ein .dmp aus einem Problem:

cargo run -p mdm-crash --bin mdm-symbolicate -- crash.dmp MisterDownloadManager-<version>-symbols-windows-x64.zip

• Testen. cargo test -p mdm-crash führt einen echten Freeze, Panic und Crash (examples/crashy.rs) aus und überprüft die Signatur jedes Berichts. Um es in der App auszuprobieren, starten Sie MDM mit MDM_CRASH_TEST=1 und führen Sie dann misterdownloadmanager /show crash-test:freeze (oder panic, crash, abort) aus.