Gedit provoque un crash

Question

J'exécute 12.04 sur un bureau Dell (qui était à l'origine fourni avec seulement 10.04 installé), et lorsque j'essaie de faire glisser un onglet Gedit d'une fenêtre à une autre, le système entier se bloque, résoluble uniquement avec un redémarrage dur. Je ne sais pas comment obtenir un fichier .crash à partir de cela et j'aurai besoin d'une assistance supplémentaire car:

Je suis au milieu des finales et je n'ai pas la chance de m'informer
la seule chose que je puisse faire une fois que le crash se produit est de changer d'espace de travail et d'ouvrir un terminal avec les commandes du clavier (bien que dans le terminal, les caractères alphanumériques soient tout ce qui fonctionne - la barre d'espace ne fait rien et la saisie ne fait pas non plus.

Quelqu'un d'autre a-t-il vu ce problème? Une recherche rapide n'a rien donné.

Eliah Kagan · Answer

Éviter les redémarrages durs

Les redémarrages durs ne sont presque jamais nécessaires. Si vous vous trouvez dans une situation où vous pensez que vous devrez peut-être effectuer un redémarrage matériel, vous devez d'abord essayer ces alternatives, dans cet ordre:

Presse Ctrl+Alt+F1. Puis appuyez Ctrl+Alt+Delete. Cela s'arrête et redémarre normalement.
Si cela échoue, vous pouvez faire quelque chose qui est presque aussi puissant qu'un redémarrage dur, mais qui diminue le risque de perte de données et d'autres conséquences négatives possibles d'un redémarrage dur. Maintenez Alt et SysRq et, dans l'ordre, appuyez sur R E I S U B. (Maintenez enfoncée Alt et SysRq tout le temps, mais relâchez chaque touche avant d'appuyer sur la suivante.) Voir cette page pour une explication simple de ce que cela fait, et cet article Wikipedia pour des informations plus détaillées .

Cependant, dans la situation que vous avez rencontrée et décrite dans votre question, il n'est très probablement pas nécessaire de redémarrer du tout . Il existe une technique qui fonctionnera probablement pour terminer gedit mais laisser tout le reste intact et fonctionner pleinement. Vous pouvez même signaler le bogue, mais comme il ne s'agit pas réellement d'un plantage, il ne le sera pas avec un fichier .crash.

Récupération sans redémarrage

Étant donné que la commutation des espaces de travail est possible, le système ne s'est pas complètement verrouillé. Dans ce cas, vous devriez pouvoir reprendre le contrôle complet de votre système en procédant comme suit:

Presse Ctrl+Alt+F1 pour passer de l'interface graphique à une console virtuelle.
Connectez-vous avec votre identifiant et votre mot de passe. Vous ne verrez rien apparaître à l'écran lorsque vous entrez votre mot de passe. C'est bon.
Maintenant que vous disposez d'une invite de shell (comme dans l'application Terminal GUI), terminez tous les processus gedit avec killall gedit. Veuillez noter que vous perdrez tout travail non enregistré dans les fenêtres/onglets gedit.
Courir killall gedit à nouveau pour voir si cela a fonctionné la première fois. S'il dit gedit: no process found c'est bien - cela signifie que vous avez terminé avec succès gedit. S'il ne dit pas cela, alors gedit ne répond pas à SIGTERM (la manière "sympa" de demander l'arrêt d'un processus). Dans ce cas, terminez-le avec SIGKILL en exécutant killall -KILL gedit. Parfois, un processus est en veille sans interruption, ce qui signifie qu'il attend une opération d'E/S du noyau et ne peut même pas être interrompu de cette façon. Pour vérifier cela, exécutez killall -KILL gedit encore.
Presse Ctrl+Alt+F7 pour revenir à l'interface graphique, qui devrait maintenant être entièrement fonctionnelle.

En supposant que l'interface graphique est entièrement fonctionnelle, le problème réside dans l'interaction entre gedit et certains composants de l'interface graphique - il pourrait s'agir de X11 lui-même ou de votre gestionnaire de fenêtres (qui pourrait être compiz, metacity, openbox, ou autre, selon l'interface graphique que vous utilisez). Cela peut être dû à un bogue dans gedit ou dans votre gestionnaire de fenêtres (ou X11). Avant de signaler le bogue, il serait préférable pour vous d'enquêter. Sean Davis conseil est bon. Vous devez savoir quel gestionnaire de fenêtres vous utilisez. Cette question peut vous aider. Dans les versions récentes d'Ubuntu, 3D Unity utilise compiz et Unity 2D utilise metacity. Vous pouvez utiliser la commande ps et grep pour voir si un processus est en cours d'exécution, si vous connaissez son nom. Par exemple, vous pouvez utiliser ps x | grep compiz pour voir si vous exécutez compiz ou ps x | grep metacity pour voir si vous exécutez metacity. Comme le dit Sean Davis, si vous exécutez Unity, essayez Unity 2D (c.-à-d. Cliquez sur l'icône d'engrenage sur l'écran de connexion et sélectionnez Ubuntu 2D ) et voir si le problème persiste.

Lancement du processus de rapport de bogue

Une fois que vous avez rassemblé ces informations, allez-y et signalez le bogue. Un crash se produit lorsqu'un programme se termine anormalement. Ce bogue n'est pas un plantage, il n'y aura donc pas de fichier .crash et Apport ne pourra pas s'exécuter automatiquement pour collecter des données. Mais vous pouvez toujours utiliser Apport pour collecter des données pertinentes pour signaler le bogue. Il existe deux façons raisonnables de procéder.

Une option consiste à exécuter ubuntu-bug, en passant un nom de package comme argument. Cela rassemblera des données sur la façon dont le package est installé et configuré sur votre système et le joindra à votre rapport de bogue. Vous devez spécifier le package qui, selon vous, est le plus susceptible de provoquer le problème. Si le problème se produit dans 3D Unity (type de session "Ubuntu") mais pas dans Unity 2D (type de session "Ubuntu 2D"), il s'agit probablement de compiz alors exécutez ubuntu-bug compiz. (De même, si le problème se produit seulement avec Unity 2D, vous pouvez exécuter ubuntu-bug metacity.) Sinon, allez-y et signalez-le contre gedit lui-même avec ubuntu-bug gedit.

Fonctionnement ubuntu-bug compiz contient de nombreuses informations sur compiz, mais ubuntu-bug gedit contient moins d'informations sur gedit. Donc, si vous pensez que le bogue se trouve dans gedit et que vous êtes prêt à faire un effort supplémentaire, vous voudrez peut-être appeler Apport pendant que gedit est en cours d'exécution, pour inclure des informations sur le exécution du processus gedit. Étant donné que votre interface graphique ne fonctionne pas lorsque le bogue se produit, vous devez le faire à partir de la console virtuelle, entre les étapes 2 et 3 ci-dessus. Voici comment:

Reproduisez le bogue en faisant glisser un onglet d'une fenêtre gedit vers une autre.
Exécutez les étapes 1 et 2 des instructions ci-dessus.
Déterminez l'ID de processus du processus gedit en cours d'exécution en exécutant la commande pidof gedit. Cela vous donnera un nombre, le PID du processus gedit en cours d'exécution.
Tapez script et appuyez sur entrée. Cela enregistre tout le texte sur la console.
Courir apport-cli $PID, mais remplacez $PID avec l'ID de processus du processus d'édition en cours tel que déterminé à l'étape 3.
Fournissez toutes les informations demandées par Apport sur la ligne de commande. Vous devriez obtenir une URL. Ce sera long et aléatoire, et donc très difficile à retenir. C'est pourquoi vous avez exécuté script pour tout enregistrer.
Exécutez exit (pour quitter script).
Tuez gedit et revenez à l'interface graphique en effectuant les étapes 3, 4 et 5 des instructions ci-dessus.
script a créé un fichier appelé TypeScript, situé directement dans votre répertoire personnel. Recherchez ce fichier et ouvrez-le avec gedit ou un autre éditeur de texte. Copiez-en l'URL et ouvrez-la dans votre navigateur Web.
Vous aurez la possibilité d'écrire un rapport de bogue dans votre navigateur Web.

Rédaction et soumission de votre rapport de bogue

Quelle que soit la manière dont vous signalez le bogue, vous rédigez un rapport dans votre navigateur Web et le soumettez. Le rapport doit être aussi détaillé que possible. Il devrait décrire comment produire le bogue, la version du package pour gedit et le package fourni par votre gestionnaire de fenêtres (par exemple, compiz ou metacity), et une explication des conditions requises pour que le bogue se produise (par exemple, se produit-il dans toutes les interfaces, ou seulement Unity 3D, ou autre chose).

Avant de soumettre votre rapport de bogue, assurez-vous de lire attentivement cette page si vous ne l'avez pas déjà fait.

Après avoir soumis votre rapport de bogue, il est conseillé d'ajouter tous les packages supplémentaires que vous pensez susceptibles d'être affectés. Habituellement, il est clair quel paquet est affecté par un bogue, mais dans ce cas, il n'est pas complètement clair. Même si le problème se produit avec compiz et non metacity, il pourrait toujours y avoir un problème dans gedit lui-même contribuant au bogue.

Si vous avez signalé le bogue contre compiz (ou metacity ou un autre gestionnaire de fenêtres), vous pouvez ajouter le package gedit comme affecté. Si vous l'avez signalé par rapport au package gedit parce que vous avez pu produire le bogue avec au moins deux gestionnaires de fenêtres différents, vous ne devez pas ajouter de package de gestionnaire de fenêtres affecté (sauf s'il existe un gestionnaire de fenêtres avec lequel vous avez découvert que le bogue ne se produit pas pas). Au lieu de cela, vous pouvez ajouter le package xorg.

Pour ajouter un autre package en plus de celui contre lequel vous avez initialement signalé le bogue, accédez à la page des bogues sur Launchpad (si vous n'y êtes pas déjà) et cliquez sur Also affects distribution. Spécifiez Ubuntu comme distribution (puisque vous dites que cela affecte un autre package dans Ubuntu). Spécifiez ensuite le nom du package supplémentaire qui, selon vous, peut être affecté, comme nom de package.

Avec plus d'un package répertorié pour le bogue, il est probable (mais pas certain) que tous sauf un seront considérés comme incorrects et marqués comme non valides. C'est bon. Mais en signalant le bogue de tous les packages qui semblent susceptibles d'être affectés, vous donnez aux trieurs de bogues et aux développeurs de ces packages la possibilité d'examiner votre bogue et de déterminer s'ils pensent que cela affecte leur package. (Mais j'insiste sur le fait que généralement vous ne devriez pas faire cela, car généralement il est possible de comprendre, peut-être avec l'aide de la communauté, quel package contient un bogue avant le signaler.)

Sean Davis · Answer

Quel environnement utilisez-vous? Il peut être lié au compositeur si vous utilisez Unity ou Gnome Shell. Essayez d'utiliser Unity 2D et voyez si le même problème se produit.