2012-01-08 17 views
6

Hay una biblioteca externa con la que estoy trabajando que frecuentemente vincula mi CPU. Me gustaría ayudar al autor a solucionarlo (ya que realmente me gusta la biblioteca), pero no sé cómo depurar el bloqueo correctamente.Cómo depurar Emacs lisp que hace que Emacs se bloquee/use 100% de CPU?

¿Alguna sugerencia para depurar Emacs lisp? Tenga en cuenta que cuando falla, Emacs ya no funciona y tengo que matarlo (por lo que las soluciones dentro de Emacs pueden no ser útiles).

Editar: Debo aclarar que está compilado en byte, y este problema no siempre ocurre para otros, por lo que puede ser específico para mis archivos de arquitectura/init. Definitivamente está relacionado con esta biblioteca.

+0

Si no se trata de un bucle infinito sino de un código realmente complicado, ¿ha considerado intentar compilarlo en byte antes de usarlo? –

+0

Está compilado en bytes. ¡Gracias! –

+0

No soy bueno con backtraces, y sospecho que tampoco lo es, pero adjuntarlo con un depurador e imprimir un seguimiento podría ayudar a reducir un poco la búsqueda. Aparte de eso, rocía el código con impresiones de depuración ... – tripleee

Respuesta

6

Primero, siempre depure la versión no compilada de un programa Emacs-Lisp, a menos que esté convencido de que el problema es introducido por el compilador de bytes.

En segundo lugar, si el código está colgando Emacs, entonces el código probablemente esté en un bucle infinito con inhibit-quit bound non-nil. Entonces, lo primero que hay que hacer es ir a través de la fuente de la biblioteca y cambiar todas las referencias de inhibit-quit a otra cosa para que C-g trabaje para detener el bucle. Después de eso, cargue la biblioteca, establezca debug-on-quit en t y obtenga un buen seguimiento de depuración cuando presione C-g que le muestra dónde está el código en bucle. A partir de ahí, la depuración del problema debería ser tan simple como la depuración de cualquier otro bucle infinito.

+0

El problema con el uso no compilado es que básicamente no se puede usar debido a su rendimiento. Veré si hay llamadas 'inhibit-on-quit' en la base de código, es una buena decisión. –

+0

No hay llamadas 'inhibit-on-quit'. Voy a probar la cosa 'debug-on-quit'. –

+0

inhibit-quit no inhibit-on-quit. Normalmente estaría vinculado así: (let ((inhibit-quit t) ...) ... algún código ...) –

Cuestiones relacionadas