Melhor depuração do Emacs?

Embora o Emacs (24.3.93.1) funcione bem se for iniciado a partir do Finder, se a versão do terminal for iniciada:

/Applications/Emacs.app/Contents/MacOS/Emacs -nw

O Emacs trava com:

Fatal error 11: Segmentation fault[1] 51512 abort /Applications/Emacs.app/Contents/MacOS/Emacs -nw.

Parece que o problema foi causado por uma única linha no init.el,

(set-face-attribute 'default nil :font "Menlo-16")

Se essa linha for comentada, a versão do terminal do Emacs também começará bem.

Para identificar a causa do acidente, levei várias horas (diminuindo meu init.el pela metade).

Estou ciente de que, em qualquer caso, o Emacs herdará qualquer fonte e tamanho de fonte especificados no aplicativo de terminal (basicamente, essa linha não é significativa no CLI).

De um modo geral, existe uma maneira melhor de depurar um Emacs com falha? Talvez usando algum tipo de depurador cli que imprima uma mensagem mais descritiva?
Por que essa linha está travando o Emacs via CLI, mas não se for lançada a partir do Finder?

— gsl
fonte

é realmente o lançamento do CLI? ou iniciar a versão do terminal que está causando o problema? Tente colocar algum erro ao redor do atributo set-face-atributo? (condição caso err (set-face-atributo ...) (erro (mensagem "Gritos!")))

— Ferrier nic

Arquive um relatório de bug. O Emacs nunca deve travar devido ao código lisp. Mas isso pode ser um problema com a compilação específica que você está usando, é o lançamento oficial?

— Malabarba 27/09/14

@ nic-ferrier: agora tenho apenas uma linha no init.el, (condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!")))ainda tenho a mesma falha com a mesma mensagem de erro. Nenhuma mensagem adicional originada no elisp.

— GSL

@ Malabarba: Eu tentei com GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.orga partir emacsformacosx.com , e não Emacs não falhar. Portanto, deve ser um bug nas versões posteriores. Vou registrar um relatório de bug.

— GSL

Como @Malabarba indicados: Arquive um relatório de bug (imediatamente): M-x report-emacs-bug. Os desenvolvedores do Emacs o guiarão pelo que você pode fazer para ajudar a depurar o problema.

— Drew

Respostas:

Para ajudá-lo a acompanhar da próxima vez

Isso aconteceu comigo antes. Houve uma situação em que string-to-intcaiu o Emacs, e levei horas para localizar também.
Desculpe, mas não posso fornecer uma resposta melhor, mas as falhas do Emacs ocorrem no fundo do código C, e não há ferramentas internas disponíveis para rastrear esses problemas.

Suponho que a depuração gdbseja possível, mas sua eficácia dependerá da sua proficiência gdb.

O que você realmente precisa fazer é

Arquivar um relatório de bug

O código elisp puro (sem compilação de bytes) nunca deve travar o Emacs. Isso pode causar um travamento (devido a algum loop infinito) e o Emacs fica sem memória. Mas, além disso, qualquer falha é um bug .

M-x report-emacs-bug

Simplesmente fornecer este exemplo minimamente elaborado, juntamente com uma descrição de sua construção e sistema, deve ser ajuda suficiente para os desenvolvedores gentis.

— Malabarba
fonte

Usar o gdb seria o único caminho. Poderíamos adicionar coisas ao Emacs para agrupar todas as chamadas C em algo que pudesse ser capturado automaticamente, mas que seria sobrecarregado o tempo todo. O Emacs não deve travar, se isso acontecer, devemos lidar especificamente com esse bug para que ele não acerte mais. Então, sim, se estiver quebrado, registre um bug. Use o gdb por todos os meios para descobrir absolutamente onde está o erro.

— Ferrier nic

Como referência para depurar com o gdb, você deve usar o src / temacs na árvore de construção. Este é o Emacs sem o elisp pré-despejado que confunde o depurador.

gdb --args src/temacs -nw

— stsquad
fonte

Obrigado, excelentes conselhos (e não é fácil encontrar por aqui também). Obrigado.

— Gsl #