10

When an error occurs inside a process sentinel or during font-locking, then Emacs doesn't show a backtrace even though debug-on-error was previously enabled.

I understand why these errors are caught, the same error might be triggered again while trying to present the backtrace. However when I want to actually debug that error it is not very helpful. I would rather risk Emacs becoming unresponsive than having to work from this:

error in process sentinel: Wrong type argument: stringp, nil

After all I can just start a second instance, if the first starts going crazy. A little more context would help when there are many places where such an error could theoretically occur in a sentinel.

So how can I force Emacs to show a backtrace even in cases where debug-on-error has no effect?

tarsius
  • 25,298
  • 4
  • 69
  • 109
  • 1
    I have seen http://emacs.stackexchange.com/questions/3552/how-to-debug-errors-in-sentinels-and-during-font-lock but think there should be a question about this in general, not just one particular case. Also I really hope "use printf" is not the only answer, because that's what I have used in the past, and it's not satisfying, especially if the error is "Invalid face reference: some-face-which-i-absolutely-know-exists", which could be triggered by pretty much every package I have installed. – tarsius Nov 14 '14 at 18:08
  • The URL points to this question and is therefore rather confusing in your comment, is it intentional or an error on your behalf? – wasamasa Nov 14 '14 at 19:28
  • That's the issue I meant: ttp://emacs.stackexchange.com/questions/1045/how-to-debug-startup-problem-if-debug-init-has-no-effect – tarsius Nov 14 '14 at 19:39
  • the link tarsius intended: http://emacs.stackexchange.com/questions/1045/how-to-debug-startup-problem-if-deb‌​ug-init-has-no-effect – dcorking Dec 30 '15 at 09:47

1 Answers1

9

For process sentinels, I don't think there's a good reason. IOW I think it's just a missing feature, so I suggest you M-x report-emacs-bug.

For font-lock, the issue is more tricky because what really happens is that the error is triggered during jit-lock, i.e. during redisplay, and we can't easily enter the debugger at that moment (IIRC at some point Gerd tried to make it work, but there were some serious problems, still). So you can debug it in one of the following ways:

  • M-x jit-lock-debug-mode which changes jit-lock to run right after redisplay, so that we can enter the debugger.
  • M-: (setq font-lock-support-mode nil) RET and then disable+reenable font-lock. This way font-lock does not use jit-lock any more, so it runs during the user's command rather than during the subsequent redisplay.
Stefan
  • 26,154
  • 3
  • 46
  • 84
  • Actually, `debug-on-error` seems to work fine on process sentinels. – Stefan Dec 23 '14 at 04:25
  • @tarsius - please post a link to your debbugs issue – dcorking Dec 30 '15 at 09:54
  • tarsius's feature request is [19432](http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19432) where it is tagged as unreproducible. Stefan Monnier posted a workaround there that uses `--eval` rather than `--debug-init` . Also his workaround doesn't help me drop into a backtrace in my actual `.emacs.d` – dcorking Dec 30 '15 at 10:42
  • 1
    @dcorking: no, in bug#19432, I did not post a "workaround" but a failed attempt to reproduce his bug. Why don't you send a recipe to reproduce your problem? – Stefan Dec 04 '17 at 13:28