Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?]

[Stefan Monnier <monnier@iro.umontreal.ca>]

Alan Mackenzie [2022-07-02 20:27:32] wrote:
> 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?

It meant "stashing".

>> .... 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

I don't see the "above" that explains why you think it's going to
be BIG.  Neither do I understand why you think it would be 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.

As I mentioned in another message, I think it would make sense to
"always" stash backtraces when we get an unhandled error, and then to
offer a way to investigate these "post mortem".  Think of it as Emacs's
equivalent of Unix's core dumps.

>> 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.

I don't think it's should be terribly hard.  We already support multiple
specpdl and switching between them for the purpose of threads, so most
of the delicate part of the code is already written.

>> 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?

Yes.


        Stefan