GNU bug report logs - #80154
odd max-lisp-eval-depth overrun error

Previous Next

To reply to this bug, email your comments to 80154 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: odd max-lisp-eval-depth overrun error
Date: Thu, 8 Jan 2026 17:01:45 +0100

Emacs master (804f965577): first define

  (defun triangle (x) (if (zerop x) 0 (+ x (triangle (1- x)))))

and evaluate

  (triangle 1000)

I get:

  Entering debugger...
  Lisp nesting exceeds ‘max-lisp-eval-depth’

Maybe we should have tried harder to enter the debugger (lifting max-lisp-eval-depth a bit higher, temporarily?) but I suppose it's not a big problem.
However, when evaluating (triangle 1000) again:

  Entering debugger...
  cl--generic-build-combined-method: Cyclic definition: cl-generic-generalizers

Where did that come from?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 80154 <at> debbugs.gnu.org
Subject: Re: bug#80154: odd max-lisp-eval-depth overrun error
Date: Thu, 08 Jan 2026 12:08:44 -0500

> Emacs master (804f965577): first define
>
>   (defun triangle (x) (if (zerop x) 0 (+ x (triangle (1- x)))))
>
> and evaluate
>
>   (triangle 1000)
>
> I get:
>
>   Entering debugger...
>   Lisp nesting exceeds ‘max-lisp-eval-depth’
>
> Maybe we should have tried harder to enter the debugger (lifting
> max-lisp-eval-depth a bit higher, temporarily?) but I suppose it's not
> a big problem.
> However, when evaluating (triangle 1000) again:
>
>   Entering debugger...
>   cl--generic-build-combined-method: Cyclic definition: cl-generic-generalizers
>
> Where did that come from?

I suspect the patch below fixes your problem.


        Stefan


diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
index 405500c0987..b8ac3e13d9a 100644
--- a/lisp/emacs-lisp/cl-generic.el
+++ b/lisp/emacs-lisp/cl-generic.el
@@ -872,7 +875,12 @@ cl--generic-build-combined-method
              (puthash (cons generic methods) :cl--generic--under-construction
                       cl--generic-combined-method-memoization)
              (condition-case nil
-                 (cl-generic-combine-methods generic methods)
+                 (unwind-protect
+                     (cl-generic-combine-methods generic methods)
+                   ;; Don't let the `:cl--generic--under-construction' linger
+                   ;; when `cl-generic-combine-methods' signals an error.
+                   (puthash (cons generic methods) nil
+                            cl--generic-combined-method-memoization))
                ;; Special case needed to fix a circularity during bootstrap.
                (cl--generic-cyclic-definition
                 (cl--generic-standard-method-combination generic methods))))))

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 80154 <at> debbugs.gnu.org
Subject: Re: bug#80154: odd max-lisp-eval-depth overrun error
Date: Fri, 9 Jan 2026 11:34:32 +0100

8 jan. 2026 kl. 18.08 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> I suspect the patch below fixes your problem.

It does, thank you!

Regarding the lack of debugger backtrace in this case, we enter `debug` via `eval-expression--debug` called from `signal_or_quit` who generously supplied us with 20 credits lisp_eval_depth which isn't nearly enough here. Cf. `call_debugger`:

  /* The previous value of 40 is too small now that the debugger
     prints using cl-prin1 instead of prin1.  Printing lists nested 8
     deep (which is the value of print-level used in the debugger)
     currently requires 77 additional frames.  See bug#31919.  */
  max_ensure_room (100);

Apart from the inconsistency here, we should probably boost the headroom a lot more if we are at all serious about helping the user locate the source of runaway recursion.

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 80154 <at> debbugs.gnu.org
Subject: Re: bug#80154: odd max-lisp-eval-depth overrun error
Date: Fri, 9 Jan 2026 17:22:18 +0100

> Regarding the lack of debugger backtrace in this case, we enter `debug` via `eval-expression--debug` called from `signal_or_quit` who generously supplied us with 20 credits lisp_eval_depth which isn't nearly enough here.

Now fixed on master, in the time-honoured way of raising some limits and calling it a day.

With Stefan's cl-generic fix that should be it.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 80154 <at> debbugs.gnu.org
Subject: Re: bug#80154: odd max-lisp-eval-depth overrun error
Date: Fri, 09 Jan 2026 14:19:56 -0500

> With Stefan's cl-generic fix that should be it.

I pushed a different patch which should also fix the problems (it did on
my end) but simplifies the code a bit, along the way.
Can you confirm that it also fixes it for you?


        Stefan

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 80154-done <at> debbugs.gnu.org
Subject: Re: bug#80154: odd max-lisp-eval-depth overrun error
Date: Fri, 9 Jan 2026 21:48:01 +0100

9 jan. 2026 kl. 20.19 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> I pushed a different patch which should also fix the problems (it did on
> my end) but simplifies the code a bit, along the way.
> Can you confirm that it also fixes it for you?

Confirmed. Nicer to avoid an unnecessary signal, I agree.

Closing!

Previous Next

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