Trying to debug a problem with debug-on-error. Backtrace appears for a second and then some other parts of the system make it disappear and emacs becomes dysfunctional so I can never read it.

Is there a way to get emacs to write the backtrace to a file when its generated?

  • 1
    If you type M-x list-buffers is your backtrace buffer still there and you can just switch to it? Unless you exited recursive-edit or killed the backtrace buffer, the backtrace buffer may still be present. – lawlist Mar 12 '17 at 1:32
  • You may wish to try advising the function debug so that the your save buffer function gets triggered after the buffer is populated. – lawlist Mar 12 '17 at 1:36

Do you see the same problem when you start Emacs using emacs -Q (no init file)? If not then recursively bisect your init file to find out what is causing the problem (e.g. *Backtrace* seeming to disappear and Emacs becoming dysfunctional).

If you still see the problem with emacs -Q then consider reporting an Emacs bug.

If buffer *Backtrace* has not been killed then you can visit it again (C-x b) and then write it to a file using C-x C-w. (Since it is not visiting a file there is no autosaving or backup file produced for the buffer.)

[Your question is anyway unclear in some respects. Specify what exactly you mean by "emacs becomes dysfunctional", for example.]

  • 1
    Its a bug with spacemacs github.com/syl20bnr/spacemacs/issues/8485 which is like, the mother of all init files; impossible to bisect. I mean, I do know what neighborhood the error lives in, it has to do with a bad interaction between the mu4e mail layer and helm. They ask for a backtrace but I simply can't capture it because helm replaces features like C-x b and C-x C-w and helm is whats crashed. – Michael Fox Mar 12 '17 at 12:57
  • 1
    Glad you're making progress debugging it. If it is a spacemacs bug why can't you repro it without involving helm? Try to keep your repro recipe as simple as possible. – Drew Mar 12 '17 at 16:51

Your Answer

