Pregunta:
Busco ideas, cómo diagnosticar la razón por la que Emacs se congela (con lo que me refiero a tomar el 100% de la CPU y ser irresponsable durante algún tiempo). Esta pregunta no se trata de un caso específico¹ sino de un enfoque …
¿Es posible preguntarle a Emacs "muéstrame / volcar en algún lugar los rastros actuales de la pila de todos los hilos Lisp que se están ejecutando"? ¿O tal vez "volcar el rastro de la pila en 10 segundos en alguna parte"? Algo que podría hacer para comprobar qué está pasando una vez que vea mis emacs congelados …
¿O es posible habilitar algún tipo de creación de perfiles global (con la salida puesta en algún archivo de disco a intervalos regulares) para que pueda buscar allí al posible culpable?
¿O hay algún otro truco? ¿Qué harías si vieras que Emacs se comporta mal y dividir todas las bibliotecas no parece prometedor²?
¹ Actualmente tengo dos problemas:
de vez en cuando, Ctrl-Y tarda entre 10 y 30 segundos (y Emacs toma el 100% del núcleo de la CPU durante este tiempo),
de vez en cuando, Emacs se vuelve lento (aunque funciona más o menos correctamente), y resulta que uno de los procesos de Emacs toma el 100% de la CPU
Ambos seguramente están relacionados con algún código lisp falso (cargo muchos módulos melpa) o causados por una relación inesperada de algunos módulos, y es bastante probable que sea mi configuración muy específica lo que los hace aparecer.
² Mi problema actual apareció después de que hice una actualización de paquete importante que instaló muchas versiones actualizadas de varios paquetes y al que también agregué un par de módulos nuevos. Bisecar eso no parece prometedor, ya que a veces toma uno o dos días antes de que aparezca el problema, volver a las versiones antiguas para siempre tampoco es algo que me gustaría …
Respuesta:
(Idea extraída de una de las preguntas sugeridas por legoscia)
Parece que matar emacs con SIGUSR2 hace exactamente lo que buscaba, al menos en el primer caso ( colgar el tirón ) (que volvió a aparecer cortésmente poco después de recibir este consejo). Todavía tengo que entender el stacktrace³, pero matar emacs con SIGUSR2 interrumpió muy bien la congelación y descargó el stacktrace.
Entonces, la respuesta a mi pregunta es kill -USR2 «emacspid» (o, más fácil, htop , p , k , 12 , Enter ).
³ Esto es lo que obtuve (código de bytes comentado porque contenía caracteres ilegibles): Debugger entered--entering a function: * command-error-default-function((quit) "" nil) #<subr recursive-edit>() byte-code(...) ad-Advice-recursive-edit(#<subr recursive-edit>) apply(ad-Advice-recursive-edit #<subr recursive-edit> nil) recursive-edit() debug(error (quit)) accept-process-output() semantic-c-lexer(778 1374 nil nil) semantic-lex(778 1374 nil) semantic-parse-region-default(778 1374 nil nil nil) semantic-parse-region-c-mode(778 1374 nil nil nil) semantic-parse-region(778 1374 nil) semantic-edits-incremental-parser-1() byte-code(...) semantic-parse-changes-default() semantic-parse-changes() semantic-fetch-tags() byte-code(...) semantic-idle-scheduler-refresh-tags() byte-code(...) semantic-idle-core-handler() semantic-idle-scheduler-function() apply(semantic-idle-scheduler-function nil) byte-code(...) timer-event-handler([nil 0 1 0 t semantic-idle-scheduler-function nil idle 0]) Todavía semanti c no es necesariamente culpable, ya que si bien todo lo anterior es semántico y la mayoría de los códigos de bytes comentados también, el código de bytes más profundo menciona varias funciones de persp- , tal vez la semántica desencadena algún evento que persp también se une, etc., etc. Aquí está la parte legible: byte-code("..." [persp-recursive G94967 persp-curr perspectives-hash old-hash ad--addoit-function persp-save boundp ((byte-code "..." [G94967 persp-recursive makunbound] 2)) copy-hash-table maphash #[(key new-persp) "..." [key old-hash persp cl-struct-perspective-tags v new-persp gethash 0 error "%s accessing a non-%s" persp-buffers perspective 2] 7] ad-return-value] 3)