Rapports d'erreur

Si Mister Download Manager se ferme de manière inattendue ou ne répond plus, une fenêtre de rapport d’erreur s’ouvre. Elle indique ce qui s’est passé, vous permet de lire le rapport complet et peut l’envoyer aux développeurs sur GitHub. Chaque rapport aide à résoudre le problème pour tout le monde.

Ce que vous voyez

• Mister Download Manager s’est fermé de manière inattendue : MDM a planté ou a rencontré une erreur interne et s’est fermé.
• Mister Download Manager ne répond plus : sa fenêtre n’a pas répondu pendant 8 secondes. MDM est toujours en cours d’exécution, mais figé. Arrêter et redémarrer MDM ferme la copie figée et en démarre une nouvelle. Si MDM répond à nouveau de lui-même, la fenêtre l’indique.

Dans la fenêtre :

1. Que faisiez-vous quand c’est arrivé ? est facultatif. Quelques mots, comme « J’ai ouvert Ajouter une URL », sont d’une grande aide.
2. Le rapport montre tout ce qui serait envoyé. Lisez-le d’abord si vous le souhaitez.
3. Envoyer sur GitHub ouvre le formulaire Rapport d’erreur de GitHub dans votre navigateur, déjà rempli, ainsi que le dossier qui contient le rapport. Faites glisser le fichier du rapport dans le formulaire, vérifiez-le et soumettez-le. Vous avez besoin d’un compte GitHub. Rien n’est envoyé automatiquement.
4. Si quelqu’un a déjà signalé le même problème, la fenêtre l’indique (Déjà signalé comme problème #…). Ouvrir le problème signalé l’ouvre et met votre rapport dans le presse-papiers, afin que vous puissiez l’ajouter en tant que commentaire.

Les autres boutons copient le rapport, ouvrent son dossier ou redémarrent MDM.

Ce que contient un rapport

• Ce qui s’est passé : l’erreur et l’endroit dans le code de MDM où elle s’est produite.
• La pile : l’endroit dans le code de MDM où il a planté ou s’est figé, et ce que chaque autre partie faisait.
• Le journal récent de MDM : par exemple « commande AddUrl » ou « fenêtre ouverte : add-url ».
• Le système : la version de MDM et la façon dont vous l’avez installé, votre système d’exploitation et sa version, le processeur, la langue et le thème, et le nombre de téléchargements et de files d’attente que vous avez. Ce ne sont que des décomptes.

Il ne contient pas :

• vos adresses de téléchargement ou noms de fichiers ;
• votre nom d’utilisateur, qui s’affiche comme ~ dans les chemins de dossiers.

Si un message d’erreur cite quelque chose que vous avez tapé, ce texte est dans le rapport, alors lisez-le avant de l’envoyer.

Le fichier de données de plantage (.dmp) est un instantané de ce que MDM exécutait à ce moment-là. Il aide le plus les développeurs, mais il peut contenir des fragments de ce que MDM avait en mémoire, comme des adresses de téléchargement. Il n’est joint que si vous cochez Joindre également les données de plantage.

Où les rapports sont conservés

Dans le dossier de données de MDM :

• crashes\: chaque rapport (.txt) et ses données de plantage (.dmp) ;
• logs\: le journal de MDM (mdm.log, avec les plus anciens comme mdm.1.log et ainsi de suite, 2 Mo chacun).

Le dossier de données de MDM est %APPDATA%\misterdownloadmanager sur Windows, ~/Library/Application Support/misterdownloadmanager sur macOS et ~/.local/share/misterdownloadmanager sur Linux. En mode portable, c’est le dossier data à côté du programme.

Le journal enregistre ce que MDM fait, de sorte qu’un rapport peut montrer ce qui a conduit à un problème. Pour enregistrer plus de détails, démarrez MDM avec la variable d’environnement MDM_LOG=debug.

Pour les développeurs

Comment ça marche : une deuxième copie de MDM, le moniteur, démarre à côté avec --crash-monitor. Le code de plantage se trouve dans crates/crash et crates/app/src/crash.rs.

• Capture des problèmes. Lorsque MDM plante (une exception Windows, un signal sur Linux, une exception Mach sur macOS), panique ou se fige, il demande un dump au moniteur. Un blocage est une image de la fenêtre qui s’exécute pendant plus de 8 s, vue par un thread de surveillance qui ignore le temps passé en veille. Le moniteur écrit ensuite un minidump de chaque thread de l’extérieur, via minidumper et crash-handler. Un processus planté n’écrit jamais son propre dump, ce qui est également la façon dont Firefox, Crashpad et Sentry le font.
• Lecture du dump. Le moniteur lit le dump avec rust-minidump de Mozilla. Il utilise les symboles Breakpad de la version s'ils sont trouvés, ou les informations de débogage natives à côté d'une compilation à partir des sources. La Signature du rapport (par exemple freeze in misterdownloadmanager::winui::combo_edit) reste la même pour les rapports d'un même problème, et la fenêtre recherche les problèmes existants pour celle-ci.
• Symboles. Les versions de publication conservent les tables de lignes (debug = "line-tables-only"), mais aucun téléchargement n'inclut les informations de débogage. L'intégration continue les transforme en MisterDownloadManager-<version>-symbols-<platform>.zip (tools/installer/symbols.py, en utilisant dump_syms de Mozilla), publiés à côté des autres fichiers de la version. La fenêtre de rapport récupère le zip pour sa propre version lorsqu'une pile affiche des adresses brutes.
• Un .dmp d'un problème :

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

• Test. cargo test -p mdm-crash exécute un vrai blocage, une panique et un crash (examples/crashy.rs) et vérifie la signature de chaque rapport. Pour l'essayer dans l'application, démarrez MDM avec MDM_CRASH_TEST=1, puis exécutez misterdownloadmanager /show crash-test:freeze (ou panic, crash, abort).