[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fontification error backtrace [Was: Why is it so difficult to get a
From: |
Alan Mackenzie |
Subject: |
Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] |
Date: |
Sat, 2 Jul 2022 20:27:32 +0000 |
Hello, Stefan.
On Thu, Jun 30, 2022 at 16:34:23 -0400, Stefan Monnier wrote:
> >> That's where we currently log all the errors during redisplay, since
> >> Emacs 21.1. So why this one is different?
> > It's not a single line, or a small number of lines. It could potentially
> > be a stack overflow error, generating a large backtrace, which might have
> > more lines than message-log-max.
> How 'bout stashing the backtrace data in a var (without turning it into
> text yet; that .....
Does "that" mean the stashing or the turning into text?
> .... should always be quick, safe, and painless) and then adding a
> button in the *Messages* (or *Warnings*) next to the error itself such
> that pressing the buttong shows you the actual backtrace?
I'm not sure the stashing of the backtrace data is a good idea. It's
likely to be BIG (see above), and it's fragile - the only place to
record it is in signal_or_quit, before it gets discarded by a call to
unwind_to_catch. The need to know its precise format is obviated by the
C function mapbacktrace, so we might as well just dump out the backtrace
as text in *Backtrace* at the first opportunity. There's nothing time
critical about the said dumping.
> We could even try and get fancy: instead of only stashing the
> `backtrace-frames`, we could also stash a copy of the specpdl so we
> could bring up a *Backtrace* buffer which isn't quite "live" but can
> still be used to some extent to see the values of local vars (and
> `current-buffer`) in the different activation frames.
I think that's very ambitious. Surely the time for that is when the
basic backtrace functionality is working, and the need for something
more sopisticated is perceived.
> BTW, in order to debug fontification errors, we also have
> `jit-locak-debug-mode` which postpones the jit/font-lock execution from
> within redisplay to "just a bit later" such that it can use the
> debugger. IIRC it still has some rough edges in some cases, but in
> theory it should be possible to make this work such that you can (for
> example) Edebug `font-lock.el` itself.
It does work, though, doesn't it?
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).