Re: The poor quality of Emacs's backtraces

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

14 juli 2023 kl. 22.51 skrev Alan Mackenzie <acm@muc.de>:

> Aren't we always careful?  I wasn't intending to make anything slower
> (except, marginally, the handling of errors).

Your intent is not in doubt, but the execution path is so sensitive that seemingly minor changes often have outsized effect on performance. (This cuts both ways: there have also been optimisation opportunities in what appeared to be reasonably efficient code.)

Bug#64613 has been opened for this effort, and I intend to continue it shortly. I'm certainly open for ideas about how to solve the problem efficiently and effectively.

> I have working code implementing the putting of this extra information
> into backtraces.

Writing code is the easy part. What I'm wary about is rushing a solution -- your solution -- to a problem that hasn't yet been studied in sufficient depth, and with no regard to the costs involved: not just performance but also the fact that other people, myself included, will be the ones to maintain the feature for all foreseeable future.

The problem is compounded by our current suboptimal representation of closures: instead of the typical ⟨function, environment⟩ tuple, we represent them as copies of the function object with closed-over variables allocated separately and hacked into the (also copied) constant vector. Making that copied function object even bigger is the opposite of what we want to do.

There is also the question of what information should be there if any were to be added. For example, source location could arguably be more useful than function name.

But more importantly, since you said yourself that you would have been satisfied with a backtrace that included the faulting operation, and we agree that this is something we want in any case, wouldn't it make sense to begin there? The risk is much lower and it won't saddle us with irreversible maintenance costs.