Re: The poor quality of Emacs's backtraces

[Alan Mackenzie <acm@muc.de>]

Hello, Mattias.

On Fri, Jul 14, 2023 at 14:35:32 +0200, Mattias Engdegård wrote:
> 14 juli 2023 kl. 12.48 skrev Alan Mackenzie <acm@muc.de>:

[ .... ]

> The fault is perhaps closer to (my?) home: the bytecode interpreter
> doesn't add a stack frame for many built-in ops. For example, (cdr 3)
> will signal a `wrong-type-argument` error but `cdr` isn't in the
> backtrace.

We can't afford to add stack frames for things like cdr.  It would make
Emacs _far_ too slow.

> That is something we could and should fix. At least for some ops it
> should be pretty easy, and even a partial remedy would be helpful.
> Alan, thank you for bringing this to my attention!

My idea for fixing this problem would be to add an extra parameter to
the CHECK_LIST (C) macro, the (symbol of) the primitive which is using
cdr.  This would be output in the backtrace error message.

There are only 1,728 occurrences of CHECK_* in the Emacs C sources.
Much of the amendment could be automated.

> > My enhancement is to store the @dfn{defining symbol} of anonymous
> > functions inside the function, whether an interpreted function, or
> > either type of compiled function.  This symbol is the defun/defmacro
> > etc. within which the lambda is defined.

> Well, no, this isn't necessarily an improvement. If anything our
> function objects are too fat; making them more so isn't what we need.

Why?  Yesterday evening, the identity of {comp-spill-lap-function} was
very helpful in locating the buggy source.

Do you have any alternative mechanism in mind for identifying anonymous
functions in backtraces?  After all, there is nothing particularly wrong
with the fatness of our function objects, provided it is not taken to
extremes - RAM is cheap and plentiful.

-- 
Alan Mackenzie (Nuremberg, Germany).