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?

Improve this question
4
  • 1
    I have seen emacs.stackexchange.com/questions/3552/… 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
    Commented Nov 14, 2014 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
    Commented Nov 14, 2014 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
    Commented Nov 14, 2014 at 19:39
  • the link tarsius intended: emacs.stackexchange.com/questions/1045/…‌​ug-init-has-no-effect
    – dcorking
    Commented Dec 30, 2015 at 9:47

1 Answer 1

Reset to default
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.
Improve this answer
4
  • Actually, debug-on-error seems to work fine on process sentinels.
    – Stefan
    Commented Dec 23, 2014 at 4:25
  • @tarsius - please post a link to your debbugs issue
    – dcorking
    Commented Dec 30, 2015 at 9:54
  • tarsius's feature request is 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
    Commented Dec 30, 2015 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
    Commented Dec 4, 2017 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.