GNU bug report logs - #28280
assert in newline

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28280 in the body.
You can then email your comments to 28280 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Maximally unhelpful diagnostic message.
Date: Tue, 29 Aug 2017 18:41:40 +0000

Hello, Emacs.

In GNU Emacs 25.2.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.16)
of 2017-08-15 built on ACM
Configured using:
  'configure --with-gif=no --with-tiff=no --with-gpm'

Configured features:
XPM JPEG PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11


I was just debugging some code when I was presented with the diagnostic:

    Assertion failed: (eq 10 (char-before))

.  Just that.  Nothing else.  No backtrace, no context, no nothing.
This is not helpful.

I request that consideration be given to providing one or more of these
details when assertion code triggers.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Glenn Morris <rgm <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Tue, 29 Aug 2017 15:20:23 -0400

Alan Mackenzie wrote:

>     Assertion failed: (eq 10 (char-before))

A few seconds grep suggests this is due to the code in newline, added ~
3 years ago in 62ee8b1 ("Add assertions to try and help catch bug#18913").
The complete lack of progress in that report since then suggests it may
be time to remove/downgrade those assertions.

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Alan Mackenzie <acm <at> muc.de>, 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Tue, 29 Aug 2017 12:32:35 -0700

>>>>> "GM" == Glenn Morris <rgm <at> gnu.org> writes:

GM> A few seconds grep suggests this is due to the code in newline, added ~ 3
GM> years ago in 62ee8b1 ("Add assertions to try and help catch bug#18913").
GM> The complete lack of progress in that report since then suggests it may be
GM> time to remove/downgrade those assertions.

Agreed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Alan Mackenzie <acm <at> muc.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Tue, 29 Aug 2017 20:15:57 +0000

Hello, Glenn.

On Tue, Aug 29, 2017 at 15:20:23 -0400, Glenn Morris wrote:
> Alan Mackenzie wrote:

> >     Assertion failed: (eq 10 (char-before))

> A few seconds grep suggests this is due to the code in newline, added ~
> 3 years ago in 62ee8b1 ("Add assertions to try and help catch bug#18913").
> The complete lack of progress in that report since then suggests it may
> be time to remove/downgrade those assertions.

Yes, but that's a separate problem from the essence of the bug report.
Regardless of the lack of progress on bug #18913, the information
provided by an assert being triggered is unhelpful and inadequate.

That aside, I can't see how the two assertions suggested in #18913 could
trigger the message I saw.  I'll maybe have a look at the actual patch
sometime when I'm less tired.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: npostavs <at> users.sourceforge.net
To: Alan Mackenzie <acm <at> muc.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Wed, 30 Aug 2017 08:17:24 -0400

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

Alan Mackenzie <acm <at> muc.de> writes:

> Yes, but that's a separate problem from the essence of the bug report.
> Regardless of the lack of progress on bug #18913, the information
> provided by an assert being triggered is unhelpful and inadequate.

Here is a possible M-x cl-show-assert command:

[v1-0001-New-command-to-backtrace-from-assertion-failure-B.patch (text/x-diff, inline)]

From 835486ccfaaf58476cbb0e097bed3b81adbcfebe Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Wed, 30 Aug 2017 08:12:18 -0400
Subject: [PATCH v1] New command to backtrace from assertion failure
 (Bug#28280)

* lisp/emacs-lisp/cl-lib.el (cl-show-assert): New command.
(cl-assert-last-backtrace): New variable.
* lisp/emacs-lisp/cl-preloaded.el (cl--assertion-failed): Set it.

TODO: keybinding? NEWS.
---
 lisp/emacs-lisp/cl-lib.el       | 15 +++++++++++++++
 lisp/emacs-lisp/cl-preloaded.el | 10 ++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/lisp/emacs-lisp/cl-lib.el b/lisp/emacs-lisp/cl-lib.el
index 243622a301..59bbdbca51 100644
--- a/lisp/emacs-lisp/cl-lib.el
+++ b/lisp/emacs-lisp/cl-lib.el
@@ -614,6 +614,21 @@ cl-pairlis
 
 ;;; Miscellaneous.
 
+(defvar cl-assert-last-backtrace nil
+  "Holds a list of frames from the last assertion failure.")
+
+(declare-function debugger-insert-backtrace "debug" (backtrace doxrefs))
+
+(defun cl-show-assert ()
+  "Show backtrace from last assertion failure."
+  (interactive)
+  (unless cl-assert-last-backtrace
+    (user-error "There hasn't been an assertion failure yet"))
+  (require 'debug)
+  (with-current-buffer (get-buffer-create "*Assertion Failure*")
+    (debugger-insert-backtrace cl-assert-last-backtrace t)
+    (display-buffer (current-buffer))))
+
 (provide 'cl-lib)
 (unless (load "cl-loaddefs" 'noerror 'quiet)
   ;; When bootstrapping, cl-loaddefs hasn't been built yet!
diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el
index ab6354de7c..d66a4b9726 100644
--- a/lisp/emacs-lisp/cl-preloaded.el
+++ b/lisp/emacs-lisp/cl-preloaded.el
@@ -41,13 +41,19 @@
 
 ;; The `assert' macro from the cl package signals
 ;; `cl-assertion-failed' at runtime so always define it.
-(define-error 'cl-assertion-failed (purecopy "Assertion failed"))
+(define-error 'cl-assertion-failed (purecopy "Assertion failed (\\[cl-show-assert] for backtrace)"))
+
+(defvar cl-assert-last-backtrace)
 
 (defun cl--assertion-failed (form &optional string sargs args)
   (if debug-on-error
       (funcall debugger 'error `(cl-assertion-failed (,form ,string ,@sargs)))
+    (setq cl-assert-last-backtrace (backtrace-frames 'cl--assertion-failed))
+    (autoload 'cl-show-assert "cl-lib"
+      "Show backtrace from last assertion failure." t)
     (if string
-        (apply #'error string (append sargs args))
+        (apply #'error (concat string " (\\[cl-show-assert] for backtrace)")
+               (append sargs args))
       (signal 'cl-assertion-failed `(,form ,@sargs)))))
 
 ;; When we load this (compiled) file during pre-loading, the cl--struct-class
-- 
2.14.1

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

> That aside, I can't see how the two assertions suggested in #18913 could
> trigger the message I saw.  I'll maybe have a look at the actual patch
> sometime when I'm less tired.

There is a third assertion added in [1: 62ee8b1a59] which is the one you
hit.

[1: 62ee8b1a59]: 2014-10-31 16:57:59 -0400
  * lisp/simple.el (newline): Add assertions to try and help catch bug#18913.
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=62ee8b1a59d5343197cb59d9f0a52e07a23af1d8

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

From: Glenn Morris <rgm <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Wed, 30 Aug 2017 15:51:38 -0400

Alan Mackenzie wrote:

> Yes, but that's a separate problem from the essence of the bug report.

So M-x toggle-debug-on-error, like with any error.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Thu, 31 Aug 2017 21:11:06 +0000

Hello, Glenn.

On Wed, Aug 30, 2017 at 15:51:38 -0400, Glenn Morris wrote:
> Alan Mackenzie wrote:

> > Yes, but that's a separate problem from the essence of the bug report.

> So M-x toggle-debug-on-error, like with any error.

Thanks, I'll try that when the error comes up again.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Sun, 17 Sep 2017 22:35:44 -0700

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

> GM> A few seconds grep suggests this is due to the code in newline, added ~ 3
> GM> years ago in 62ee8b1 ("Add assertions to try and help catch bug#18913").
> GM> The complete lack of progress in that report since then suggests it may be
> GM> time to remove/downgrade those assertions.
> 
> Agreed.

Make sense, so I installed the attached into emacs-26.

[0001-Remove-old-cl-assert-calls-in-newline.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: npostavs <at> users.sourceforge.net
Cc: Alan Mackenzie <acm <at> muc.de>, 28280 <at> debbugs.gnu.org,
 Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Mon, 24 Aug 2020 15:59:33 +0200

npostavs <at> users.sourceforge.net writes:

>> Yes, but that's a separate problem from the essence of the bug report.
>> Regardless of the lack of progress on bug #18913, the information
>> provided by an assert being triggered is unhelpful and inadequate.
>
> Here is a possible M-x cl-show-assert command:

[...]

> * lisp/emacs-lisp/cl-lib.el (cl-show-assert): New command.
> (cl-assert-last-backtrace): New variable.
> * lisp/emacs-lisp/cl-preloaded.el (cl--assertion-failed): Set it.

[...]

> +    (debugger-insert-backtrace cl-assert-last-backtrace t)

This patch still applies, but this function was removed in 2018, so if
we want something like this, we have to refactor out that function
again.

But...  I'm not sure a command like this makes sense.  As others noted
in this thread, if you want a backtrace (from an error or assertion),
then you set debug-on-error.

So if we want this, I think it should be even more general -- a command
to give you a backtrace of the previous error signalled, no matter
whether it was an error or an assertion.

Which I think would be a really nice thing to have -- I run Emacs with
debug-on-error on by default because of this, but if it were possible to
say `M-x debug-last-error', then I wouldn't have to.

Would this be possible to implement in an easy way, I wonder?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: npostavs <at> users.sourceforge.net
Cc: Alan Mackenzie <acm <at> muc.de>, Glenn Morris <rgm <at> gnu.org>,
 28280 <at> debbugs.gnu.org
Subject: Re: bug#28280: Maximally unhelpful diagnostic message.
Date: Sun, 11 Oct 2020 04:08:39 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So if we want this, I think it should be even more general -- a command
> to give you a backtrace of the previous error signalled, no matter
> whether it was an error or an assertion.

In any case, the reported bug here was fixed by Paul at the time, so I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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