bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31919: 26.1.50; Lisp Debugger doesn't work when at stack limit


From: Gemini Lasswell
Subject: bug#31919: 26.1.50; Lisp Debugger doesn't work when at stack limit
Date: Wed, 20 Jun 2018 17:05:41 -0700

When max-lisp-eval-depth is exceeded and that error invokes the Lisp
Debugger, it prints an error message, doesn't produce a backtrace, and
leaves Emacs in a borked state.  In Emacs 25.3.1, the Debugger works
in this situation although the rest of Emacs doesn't work well due to
being near the stack limit, but you can exit the Debugger and things
will go back to normal.

The reason for the regression is that backtrace printing is now done
in Lisp, in cl-print, instead of in C.  If cl-print isn't yet
loaded, being at the stack limit can cause it to fail to load.

To reproduce, from emacs -Q, enter this code into a buffer and
evaluate it:

(toggle-debug-on-error)
(defun my-func (arg)
  (+ (length arg) (my-func arg)))
(my-func "hello")

Result:

Instead of the *Backtrace* buffer, Emacs instead shows *Compile-Log*,
which in my case contains:

/nix/store/s6ji5vn6jbsjpp6wwbix2daigkcsvj7h-emacs-26.1.50/share/emacs/26.1.50/lisp/emacs-lisp/cl-print.elc:Error:
 Lisp nesting exceeds ‘max-lisp-eval-depth’

In the echo area, this message appears:

cl--generic-make-next-function: Symbol’s function definition is void: t

Emacs is at this point barely usable because it is inside the
debugger's recursive edit and at its stack limit, making
max-lisp-eval-depth errors easy to encounter.  The *Backtrace* buffer
exists but is empty and in Fundamental mode, so you can't use it to
quit the debugger.  You can recover from the situation with
M-x top-level RET.

If cl-print is already loaded the above example will work, but if you
evaluate the following, the Debugger buffer will appear with a
truncated backtrace:

(my-func '(1 (2 (3 (4 (5 (6 (7 (8)))))))))

Here's a patch to give the Debugger and cl-print more stack space
during the recursive edit:

>From d044dc12a2b5794bd1155fd5b7ff7adb3bc8841d Mon Sep 17 00:00:00 2001
From: Gemini Lasswell <address@hidden>
Date: Wed, 20 Jun 2018 13:58:33 -0700
Subject: [PATCH] Increase max-lisp-eval-depth adjustment while in debugger

* src/eval.c (call_debugger): Increase the amount of extra stack
depth given to the debugger to allow it to call cl-print.
---
 src/eval.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/eval.c b/src/eval.c
index ca1eb84ff3..f9bc13ade7 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -282,8 +282,8 @@ call_debugger (Lisp_Object arg)
   /* Do not allow max_specpdl_size less than actual depth (Bug#16603).  */
   EMACS_INT old_max = max (max_specpdl_size, count);
 
-  if (lisp_eval_depth + 40 > max_lisp_eval_depth)
-    max_lisp_eval_depth = lisp_eval_depth + 40;
+  if (lisp_eval_depth + 80 > max_lisp_eval_depth)
+    max_lisp_eval_depth = lisp_eval_depth + 80;
 
   /* While debugging Bug#16603, previous value of 100 was found
      too small to avoid specpdl overflow in the debugger itself.  */
-- 
2.16.4


reply via email to

[Prev in Thread] Current Thread [Next in Thread]