Bonjour, en parcourant le Web je me suis aperçu que d'autres utilisateurs avaient déjà rencontré ce problème mais je n'ai trouvé aucune solution pour le moment. Je veux parler d'emacs qui lorsqu'il est lancé me prend 100% d'un des deux coeurs de mon processeur. Bien que j'utilise emacs depuis plusieurs années, je n'avais jamais rencontré ce problème auparavant. J'ai essayé de supprimer mon fichier .emacs au cas où mais ça n'a rien changé. Bref, est ce que vous avez une idée d'où ça pourrait venir ?
# Détails
Posté par Frédéric Perrin (site web personnel) . Évalué à 2.
Cela se produit dès le lancement ? Si non, quelle commande / quel mode est responsable ?
emacs reste utilisable pendant ce temps ? Est-ce qu'un C-g permet d'interrompre l'utilisation du CPU ? Si oui, fais un M-x toggle-debug-on-quit, force de nouveau emacs à utiliser 100% du CPU, puis C-g. On saura alors où emacs était bloqué.
[^] # Re: Détails
Posté par pamputt . Évalué à 1.
Oui en fait cela se produit dès le lancement.
Je le lance simplement en console avec
> emacs
ou > emacs -Q
et le CPU s'affole directement.
Par contre, ça ne frise pas du tout mon système je peux continuer à taper du texte sans soucis.
En ce qui concerne le Ctrl-G, il n'a absolument aucun effet sur mon emacs. C'est censé faire quoi ?
[^] # Re: Détails
Posté par Frédéric Perrin (site web personnel) . Évalué à 3.
Pour revenir au sujet, je trouve étonnant qu'un emacs, programme mono-thread s'il en est, continue à être utilisable alors qu'il pompe du CPU. Je n'ai pas d'autres pistes, à moins de sortir un debugger...
Tu as dit que le problème est apparu il n'y a pas très longtemps, qu'est-ce que tu as fait entre "maintenant" et la dernière fois où ça marchait comme prévu ?
[^] # Re: Détails
Posté par pamputt . Évalué à 1.
C'est bien ça le problème, je n'ai rien fait entre le moment où emacs fonctionnait correctement et maintenant où il bouffe le CPU. Merci de ton aide.
[^] # Re: Détails
Posté par ze_lionix (site web personnel) . Évalué à 1.
Est ce que tu n'as pas mis a jour quelque choses sur ton système ?
Comme des librairies utilisée par emacs ?
Fuse : j'en Use et Abuse !
[^] # Re: Détails
Posté par Elfir3 . Évalué à 2.
ctrl-g d'abord, et ça sert à annuler une commande en cours. Ce serait donc valable si une commande est en cours mais je suppose que ce n'est pas le cas.
J'ai moi aussi fait l'expérience de ce genre de comportement un peu bizarre, mais pas dès le démarrage, après un certain temps d'utilisation. Je pense que depuis je dois l'avoir mis à jour ou changé la conf; il ne me semble plus être retombé dessus.
Serait-il possible d'avoir la liste des modules que tu as installé ? Ton ~/.emacs peut-être intéressant aussi, ainsi que les versions des modules, histoire de recouper.
[^] # Re: Détails
Posté par Michaël (site web personnel) . Évalué à 2.
Essaie plutôt
emacs -nw -Q -q
le problème vient probablement d'une package elisp que tu charges dans ton fichier de démarrage.[^] # Re: Détails
Posté par pamputt . Évalué à 1.
Donc quand j'utilise « emacs -Q -q » j'ai toujours un problème de CPU. Par contre quand je n'utilise pas l'interface graphique (emacs -nw), le CPU est calme et fonctionne normalement.
[^] # Re: Détails
Posté par Michaël (site web personnel) . Évalué à 2.
Cela vient probablement de l'interface graphique: laquelle utilises-tu? Celle avec Gtk?
Que renvoie ta première ligne de `about-emacs'? Chez moi, où tout fonctionne normalement, cela donne:
GNU Emacs 23.3.1 (amd64-portbld-freebsd8.2, GTK+ Version 2.22.1)
[^] # Re: Détails
Posté par pamputt . Évalué à 1.
Oui est exactement, cela venait de l'interface graphique. J'ai trouvé la réponse que j'explique
. Merci d'avoir pris le temps de m'aider.
[^] # Re: Détails
Posté par pamputt . Évalué à 1.
Le lien n'est pas passé, le voici https://linuxfr.org/forums/g%C3%A9n%C3%A9ralg%C3%A9n%C3%A9ral/posts/emacs-bouffe-100-du-cpu#comment-1245185
# desactive le plugin flash
Posté par NeoX . Évalué à 2.
tu as mis à jour ton plugin flash ?
tu as beaucoup d'onglet d'ouverts ?
non, je dis ca, je ne connais pas emacs, mais comme il parait qu'on peut faire à peu pres tout avec (sauf le café), je me disais que c'etait peut-etre le plugin flash qui faisait ramer ;)
:p
ah, on me dit que je suis hors sujet, tant pis ca tiendra bien jusqu'a vendredi prochain pour nourrir le troll
[^] # Re: desactive le plugin flash
Posté par bzubzu . Évalué à 1.
emacs fait le café :
http://emarsden.chez.com/downloads/coffee.el
:D
# Détails ?
Posté par Ronan BARZIC . Évalué à 5.
Désolé d'être rabat-joie mais sans info sur la version d'emacs, l'OS et éventuellemet les packages spécifiques à emacs qui ont pu être installés, c'est un peu dur d'aider d'une manière concrète
# Moi aussi
Posté par Philippe Ivaldi (site web personnel) . Évalué à -2.
J'ai exactement le même problème sur une machine mais seulement quand je lis des mp3 (pas de pb avec les ogg) avec Bongo. Pas de problème sur une autre machine avec le même os et la même config.
C'est arrivé d'un coup, avant ça marchait ; la question est « avant quoi ».
Du coup j'ai pris l'habitude de lire les mp3 avec vlc :( sans chercher plus loin…
[^] # Re: Moi aussi
Posté par Michaël (site web personnel) . Évalué à 3.
Tout est dans le exactement :)
# strace
Posté par jigso . Évalué à 1.
ça donne quoi un strace emacs -q ?
Chez moi, après une logorrhée qu'on peut aisément oublier durant la phase de démarrage, sans rien toucher dans la fenêtre, il boucle sur des blocs du genre :
--- SIGIO (I/O possible) @ 0 (0) ---
sigreturn() = ? (mask now [])
read(3, 0x9a17c48, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN}], 7, 0) = 0 (Timeout)
gettimeofday({1308577848, 533076}, NULL) = 0
read(3, 0x9a17c48, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN}], 7, 0) = 0 (Timeout)
select(15, [3 4 9 11 12 13 14], NULL, NULL, {0, 495896}) = 0 (Timeout)
gettimeofday({1308577849, 29951}, NULL) = 0
gettimeofday({1308577849, 30168}, NULL) = 0
gettimeofday({1308577849, 30290}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH IO], 8) = 0
read(3, 0x9a17c48, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN}], 7, 0) = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, [WINCH IO], [WINCH IO], 8) = 0
gettimeofday({1308577849, 31326}, NULL) = 0
rt_sigprocmask(SIG_UNBLOCK, [WINCH], [WINCH IO], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{";\0\5\0\367\0@\2\0\0\0\0\37\0\6\0010\2\17\0C\0\5\0/\0@\2\367\0@\2"..., 56}, {NULL, 0}, {"", 0}], 3) = 56
read(3, 0x9a17c48, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x9a17c48, 4096) = -1 EAGAIN (Resource temporarily unavailable)
kill(8459, SIGIO) = 0
--- SIGIO (I/O possible) @ 0 (0) ---
à raison d'un toutes les demi-secondes. Ça a l'air d'être en phase avec le clignotement du curseur, et évidemment ça ne prend pas 100% du CPU !
Peut-être que sur vos installations vous verrez quelque chose d'autre...
# J'ai trouvé
Posté par pamputt . Évalué à 3.
En voyant toutes vos réponses, j'ai eu une idée sur ce qui avait changé entre le début où ça fonctionnait correctement et maintenant. De plus, comme le CPU ne s'affole pas quand j'utilise l'option -nw, j'ai pensé à gtk-qt-engine qui permet au appli gtk d'avoir un look plus qt (peut-être utile quand on utilise KDE). Bref, je désinstalle ce truc et magie, emacs n'est plus aussi gourmand.
Il ne me reste plus qu'à ouvrir un rapport de bogue pour indiquer cela aux dév de gtk-qt-engine.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.