Forum général.général emacs bouffe 100% du CPU

Posté par .
Tags :
2
19
juin
2011

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 (page perso) . É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 . É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 (page perso) . Évalué à 3.

        C-g runs the command keyboard-quit...
        Signal a `quit' condition.
        During execution of Lisp code, this character causes a quit directly.

        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 . É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 (page perso) . É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 . Évalué à 2.

        En ce qui concerne le Ctrl-G, il n'a absolument aucun effet sur mon emacs. C'est censé faire quoi ?

        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 (page perso) . Évalué à 2.

        emacs -Q

        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.

  • # desactive le plugin flash

    Posté par . Évalué à 2.

    Bonjour, en parcourant le Web je me suis aperçu que [...] emacs [...] 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. [...]

    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

  • # Détails ?

    Posté par . É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 (page perso) . É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…

  • # strace

    Posté par . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.