emacs 24.3 sur Windows 7 ne se ferme pas correctement

J'utilise Emacs 24.3 sur une machine Windows 7. Peu importe la façon dont je ferme l'éditeur, que ce soit Ctrl+ X, Ctrl+ Cou le menu, Emacs se bloque toujours et j'obtiens l'erreur «GNU Emacs: l'éditeur de texte extensible auto-documenté a cessé de fonctionner» (illustré ci-dessous). Quelqu'un d'autre obtient-il une erreur similaire? Quelqu'un at-il une idée de ce qui pourrait être à l'origine de cela? FWIW, une erreur similaire s'est produite lors de l'utilisation d'Emacs 23 également. J'avais l'impression que cela disparaîtrait dans Emacs 24. On dirait que non. J'ai joint une capture d'écran, qui renvoie à une version pleine grandeur de lui-même .

J'inclus également le message d'erreur complet ici, pour aider davantage le dépannage:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: emacs.exe
  Application Version:  24.3.0.0
  Application Timestamp:    51461ed8
  Fault Module Name:    libgcc_s_dw2-1.dll
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   4bc96cad
  Exception Code:   40000015
  Exception Offset: 00016646
  OS Version:   6.1.7601.2.1.0.768.3
  Locale ID:    2057
  Additional Information 1: 40aa
  Additional Information 2: 40aadffc5490879468da6327c52e8317
  Additional Information 3: 30a6
  Additional Information 4: 30a67832b564ca36083716f18a2a95ef

J'avais ce problème.

Je l'ai résolu pour ma configuration en passant l' --no-splashoption à emacs au démarrage.

Je n'ai pas d'écran de démarrage maintenant, mais je ne plante pas non plus à la sortie.

Je viens d'avoir ce problème lors de la configuration d'un nouvel ordinateur portable Windows 7. La vérification de l'observateur d'événements Windows a révélé que la version de Emacs libgcc_s_dw2-1.dll était liée à était le coupable. Une analyse rapide de mon lecteur C avec Everything a abouti à pas moins de sept versions de la bibliothèque dispersées parmi différentes versions de MinGW que j'avais installées aux côtés d'autres applications, RStudio, OSGeo4W, CodeBlocks, etc. Quelques-unes d'entre elles s'étaient injectées dans mon variable de chemin d'accès système.

La solution pour moi était de s'assurer qu'Emacs a trouvé un libgcc_s_dw2-1.dll compatible ou aucun en définissant la variable PATH avant de démarrer Emacs. À partir d'un type de ligne de commande set path=pour effacer la variable de chemin d'accès avant de démarrer emacs c:\<pathtoemacsbin>\runemacs.exe, en supposant que vous n'aurez pas besoin d'accéder au chemin d'accès aux autres fichiers. Alternativement, une version récente de MinGW32 devrait être compatible. Assurez - vous qu'il est disponible sur le chemin de recherche, set path=c:\MinGW32\bin.

J'ai trouvé une seule instance de libgcc_s_dw2-1.dll sur ma machine, installée sous GNUplot.

Je l'ai renommé arbitrairement, et maintenant emacs fonctionne très bien. Bien sûr, GNUplot ne fonctionne pas, mais bon!

AFAIK, libgcc_s_dw2-1.dll est lié statiquement, donc il n'est pas pertinent l'origine du fichier.

J'ai connu les mêmes plantages et je peux confirmer deux choses:

• Pas de plantage dans emacs 24.3 construit avec gcc v3.xx

• Pas de plantage dans emacs 24.3 construit avec gcc v4.5 sjlj

Et ce fil

http://sourceforge.net/mailarchive/message.php?msg_id=27481215

pourrait confirmer le dernier point.

HTH

Vous ne dites pas si les plantages se produisent lorsque vous démarrez sans fichier init ( ~/.emacs), c'est-à-dire en utilisant emacs -Q. Si c'est le cas, vous pourriez envisager de déposer un rapport de bogue avec une recette reproductible. Sinon, divisez récursivement votre fichier init jusqu'à ce que vous trouviez le code responsable.

emacs -Q est le point de départ: (a) lors du signalement d'un problème et (b) lors du débogage.