¿Hay un truco para depurar un giro en emacs elisp, en un módulo flymake?

Question

Estoy obteniendo un giro de CPU en emacs elisp, dentro del módulo flymake de C#. (Flymake es el módulo en emacs que periódicamente ejecuta una construcción, luego resalta cualquier error de sintaxis o advertencias en el búfer en uso.)

Estoy a punto de meterme en el código, para buscar posibles lugares donde podría ocurrir un giro .

Mientras estoy en ello, ¿alguien tiene sugerencias para descubrir el giro? ¿Hay algo en emacs que me permita detener la ejecución y ver dónde se detuvo?

Answer 1

Uso M-x set-variable configurar debug-on-quit a t. Luego, cuando ocurra el problema, marque C-g y el depurador le dará una pista de lo que se estaba ejecutando cuando lo detuvo.

Answer 2

http://www.gnu.org/s/emacs/manual/html_node/elisp/Debugging.html podría ayudarle a

Answer 3

Flymake establece un temporizador de 1 segundo para cada memoria intermedia que tiene activado el modo flymake, para comprobar si el almacenamiento intermedio se ha modificado más de flymake-no-changes-timeout segundos atrás.

Si tiene muchos búferes abiertos (varios cientos) en modo flymake, entonces esto puede devorar una cantidad sorprendentemente grande de CPU, tengo una versión parcheada de flymake que tiene un solo temporizador global que corrige esto, y algunos otros problemas: https://github.com/illusori/emacs-flymake

Puede que este no sea el mismo problema para usted, pero para mí bloquearía Emacs cuando abriera en modo de escritorio con 600 archivos abiertos. Tendría la suerte de obtener una pulsación de tecla procesada cada 15 minutos.

Answer 4

En OS X tuve un problema de sonido similar donde flymake colgaría emacs al abrir un archivo nuevo (incluso con solo unos pocos búferes abiertos). Habilitar debug-on-quit no ayudó, ya que toda la GUI se bloqueó.

Colocación BGF a emacs devolvió el siguiente:

$ gdb -p `psgrep emacs` 
(gdb) bt 
#0 0x00007fff98954e42 in __semwait_signal() 
#1 0x00007fff8e5d1dea in nanosleep() 
#2 0x00007fff99e3af05 in +[NSThread sleepUntilDate:]() 
#3 0x000000010015d917 in -[EmacsDialogPanel runDialogAt:]() 
#4 0x000000010015fa1f in ns_popup_dialog() 
[...] 

Así que el bloqueo fue causado por un mensaje de diálogo que dice "Error de configuración mientras se ejecuta ..." o similar

De this post describing the problem, se puede deshabilitar estos mensajes emergentes con lo siguiente:

A veces, sin embargo, Emacs simplemente se cuelga. Los botones rojo/amarillo/azul de OS X cerrar/minimizar/zoom se vuelven grises como si Emacs hubiera perdido el foco, pero de hecho es la aplicación activa. El cambio de tareas de Emacs y su regreso no lo recupera. No puedes Command-Q salir de él.

Cuando finalmente te rindes y lo matas y reinicias, has perdido tu trabajo, tus shells, y no guarda la lista de archivos recientes.

(setq flymake-gui-warnings-enabled nil) 

Esto impide flymake de avisarle que ha de desactivarse el mismo, pero es mejor que la alternativa.

El flymake-display-warning llama a la función 'message-box' de Emac por lo que puede haber otras herramientas que causen el mismo problema.

También hay un cuadro de diálogo de uso variable genérico, pero configurarlo de forma predeterminada t a nil no ayudó con flymake.También hay una sugerencia en las interwebs para usar defadvice para decir y-o-no-p y yes-or-no-p establecer use-dialog-box en nil, pero de nuevo, esto no ayudará a flymake ya que no lo hace usa esas funciones