GNU bug report logs - #61847
debug-early-backtrace only works some of the time.

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Mon, 27 Feb 2023 17:13:01 UTC

Severity: normal

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 61847 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61847 <at> debbugs.gnu.org
Subject: Re: debug-early-backtrace only works some of the time.
Date: Tue, 28 Feb 2023 19:52:33 +0000
Hello, Stefan.

On Tue, Feb 28, 2023 at 12:36:32 -0500, Stefan Monnier wrote:
> >> To get more readable backtraces when used after bootstrapping (as well as
> >> in the later phases of bootstrapping).

> > More readable?  Just how is a backtrace produced using cl-prin1 more
> > readable than one using prin1?  They both look pretty much the same.  But
> > cl-prin1 only outputs partial information for some things, such as
> > compiled functions, so it is not a good choice.  debug-early-backtrace
> > should produce _complete_ backtraces.

> The output for compiled functions is the main one which I think is more
> readable (among those that occur often in backtraces), so let's just
> agree to disagree on this one.

No.  The point is too important not to resolve.

I think you're objectively wrong here.  The purpose of a backtrace is
not to enter a beauty contest.  Rather it's to provide the programmer
with as much information as reasonably possible to solve a bug.

The lack of output for compiled functions with cl-prin1 condemns it.  All
that appears is "#f(compiled-function)" together with an empty pair of
parentheses and a meaningless hex address.  What use is any of that in
debugging a batch mode bug?

prin1 by contrast prints the actual contents of the function - its byte
code string and its constant vector, among other things.  It may not be
as "readable", but it is infinitely more useful to the person trying to
debug a bug.

> > And how will the contition-case you suggest help?  (require 'cl-print nil
> > t) returns non-nil in the pertinent circumstances.

> The `noerror` argument of `require` doesn't silence the errors that
> happen while loading the file, instead it prevents signaling an error
> when the file is not found.

Whether that error is silenced or not is wholly unimportant.  The only
important thing here is to get a backtrace, and your patch will not help
do that.  Mine does help - I've tested it.

> > Putting a condition-case around that isn't going to change this.

> I'm hoping it will.

How can it possibly help get that backtrace?

> > Have you actually tried out your patch?

> No.

Please do so, and report.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 2 years and 141 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.