GNU bug report logs - #65622
Inappropriate suppression of backtrace on an error

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alan Mackenzie <acm <at> muc.de>
Subject: bug#65622: closed (Re: bug#65622: Inappropriate suppression of
 backtrace on an error)
Date: Wed, 20 Sep 2023 15:56:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#65622: Inappropriate suppression of backtrace on an error

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 65622 <at> debbugs.gnu.org.

-- 
65622: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65622
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: acm <at> muc.de, 65622-done <at> debbugs.gnu.org
Subject: Re: bug#65622: Inappropriate suppression of backtrace on an error
Date: Wed, 20 Sep 2023 15:55:37 +0000

Hello, Michael.

The bug is now fixed.

On Thu, Aug 31, 2023 at 01:16:42 +0200, Michael Heerdegen wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > Hello, Emacs.
> > (v) Set debug-on-error to t with M-: (setq debug-on-error t).
> > (vi) Repeat (iv).  This throws the same error, without a backtrace.  This
> >   lack of a backtrace is a bug.

> I think you just need (setq eval-expression-debug-on-error t).

> Stumbled over the same issue ... yesterday?, or so.  Also when debugging
> Edebug.

> Maybe people would like debug-on-error -> t taking precedence over
> eval-expression-debug-on-error -> nil?  The danger is they turn both off
> by default and then forget about the second one.

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

[Message part 3 (message/rfc822, inline)]

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Inappropriate suppression of backtrace on an error
Date: Wed, 30 Aug 2023 13:08:26 +0000

Hello, Emacs.

On a recent master branch Emacs:
(i) emacs -Q
(ii) Insert the following into *scratch*:

(defmacro hash-if (condition then-form &rest else-forms)
  "A conditional compilation macro analogous to C's #if.
Evaluate CONDITION at macro-expansion time.  If it is non-nil,
expand the macro to THEN-FORM.  Otherwise expand it to ELSE-FORMS
enclosed in a `progn' form.  ELSE-FORMS may be empty."
  (declare (indent 2)
           (debug (form sexp &rest sexp)))
  (if (eval condition lexical-binding)
      then-form
    (cons 'progn else-forms)))

(defun foo (bar)
  (hash-if (< emacs-major-version 19)
      (car bar)
    (cons bar bar)))

(iii) Evaluate hash-if by putting point after it and doing C-x C-e.
(iv) Attempt to instrument foo for edebug by putting point inside foo and
  doing C-u C-M-x.  This throws the error: "Ignoring macroexpansion
  error: (void-function edebug-after)".
(v) Set debug-on-error to t with M-: (setq debug-on-error t).
(vi) Repeat (iv).  This throws the same error, without a backtrace.  This
  lack of a backtrace is a bug.
(vii) This backtrace is almost certainly being suppressed by a frivolous
  condition-case, whose main purpose appears to be making debugging more
  difficult.  ;-)
(viii) There would appear to be no justification for "ignoring" the error
  (void-function edebug-after).  Such error should not occur, and needs
  debugging.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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