all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gemini Lasswell <gazally@runbox.com>
To: 31919@debbugs.gnu.org
Subject: bug#31919: 26.1.50; Lisp Debugger doesn't work when at stack limit
Date: Wed, 20 Jun 2018 17:05:41 -0700	[thread overview]
Message-ID: <87a7rprokq.fsf@runbox.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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:


[-- Attachment #2: 0001-Increase-max-lisp-eval-depth-adjustment-while-in-deb.patch --]
[-- Type: text/plain, Size: 1066 bytes --]

From d044dc12a2b5794bd1155fd5b7ff7adb3bc8841d Mon Sep 17 00:00:00 2001
From: Gemini Lasswell <gazally@runbox.com>
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	other threads:[~2018-06-21  0:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21  0:05 Gemini Lasswell [this message]
2018-06-27 17:16 ` bug#31919: 26.1.50; Lisp Debugger doesn't work when at stack limit Gemini Lasswell
2018-06-27 17:37   ` Eli Zaretskii
2018-06-28  4:26     ` Gemini Lasswell
2018-06-30  9:39       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7rprokq.fsf@runbox.com \
    --to=gazally@runbox.com \
    --cc=31919@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.