GNU bug report logs - #60768
30.0.50; edebug-instrument-function off by one

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60768 <at> debbugs.gnu.org
Subject: bug#60768: 30.0.50; edebug-instrument-function off by one
Date: Fri, 13 Jan 2023 15:05:40 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Date: Thu, 12 Jan 2023 21:27:06 -0500
> 
> 1. Save the following elisp to /tmp/test.el:
> 
> 
> --8<---------------cut here---------------start------------->8---
> ;; -*- lexical-binding: t; -*-
> 
> ;;;###autoload
> (defun one ()
>   "ONE"
>   (1+ 0))
> 
> (defun two ()
>   "TWO"
>   (1+ (one)))
> 
> (defun three ()
>   "THREE"
>   (1+ (two)))
> 
> (provide 'test)
> --8<---------------cut here---------------end--------------->8---
> 
> 2. Run emacs from the command line with the following:
> 
> emacs -Q --batch -l /tmp/test.el --eval "(progn (require 'edebug) 
> (edebug-instrument-function #'one))"
> 
> Expected output: Edebug: one
> Actual output: Edebug: two
> 
> If you repeat the test with an additional autoload cookie added 
> above function "two", function one is correctly instrumented.
> 
> If you repeat it with an autoload cookie only above function 
> "three", function two is, incorrectly, instrumented.
> 
> My hunch is find-function-search-for-symbol being thrown off 
> somehow.

It's not a real problem, and it has nothing to do with the autoload
cookie, AFAICT.  If you modify edebug.el like below:

diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 2f7d03e..0ac51ad 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -518,6 +518,7 @@ edebug-read-top-level-form
         ;; Don't enter Edebug while doing that, in case we're trying to
         ;; instrument things like end-of-defun.
         (edebug-active t))
+    (save-excursion (end-of-defun))
     (end-of-defun)
     (beginning-of-defun)
     (prog1

i.e., add one call to end-of-defun whose result is thrown away, before
the _real_ call to end-of-defun, the problems go away.

The reason seems to be that end-of-defun calls scan-sexps, and the
first call to scan-sexps does something that wasn't done before.

Stefan, any ideas what could that be?  Any hints where to look?

Previous Next

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