GNU bug report logs - #41853
28.0.50; Peculiar "args out of range" error when using Edebug

Previous Next

Full log

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 41853 <at> debbugs.gnu.org
Subject: Re: bug#41853: 28.0.50;
 Peculiar "args out of range" error when using Edebug
Date: Sun, 21 Jun 2020 17:38:34 +0200

Am So., 21. Juni 2020 um 15:40 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am So., 14. Juni 2020 um 18:23 Uhr schrieb Philipp Stephani
> <p.stephani2 <at> gmail.com>:
> >
> > Am So., 14. Juni 2020 um 17:48 Uhr schrieb Philipp Stephani
> > <p.stephani2 <at> gmail.com>:
> > >
> > > Am So., 14. Juni 2020 um 17:35 Uhr schrieb Philipp Stephani
> > > <p.stephani2 <at> gmail.com>:
> > > >
> > > > Am So., 14. Juni 2020 um 17:20 Uhr schrieb Philipp Stephani
> > > > <p.stephani2 <at> gmail.com>:
> > > > >
> > > > > Am So., 14. Juni 2020 um 16:23 Uhr schrieb Philipp Stephani
> > > > > <p.stephani2 <at> gmail.com>:
> > > > > >
> > > > > >
> > > > > > This error is somewhat common when using `edebug-all-defuns'.  It's not
> > > > > > easy to reproduce with a minimal example, but happens in real-world
> > > > > > code.  For example, the following recipe works for me consistently:
> > > > > >
> > > > > > 1. Clone the Flycheck repository at commit
> > > > > >    c02cd773dded0215f9417ec04dfe8dabda63ef43 (probably most other commits
> > > > > >    also work, this is just for reproducibility).
> > > > > >
> > > > > > 2. Clone the dash.el repository at commit
> > > > > >    ea4a4cc7cce7c3b93862a22df8bca8b83052ccbf (probably the exact commit
> > > > > >    doesn't matter here as well).
> > > > > >
> > > > > > 3. Visit flycheck.el like so:
> > > > > >
> > > > > >    emacs -Q -L /src/dash.el/ -l edebug -f edebug-all-defuns \
> > > > > >      -f toggle-debug-on-error flycheck.el
> > > > > >
> > > > > > 4. M-x eval-buffer
> > > > > >
> > > > > > 5. Step through macro expansions using the `G' key.  Repeat until
> > > > > >    `eval-buffer' is complete or has signalled and error.
> > > > > >
> > > > > > 6. At some point, there will be an error
> > > > > >
> > > > > >    edebug--display: Args out of range: [66 86 129 138 139], 5
> > > > > >
> > > > > >    without invoking the debugger or backtrace.
> > > > > >
> > > > > > This looks like a bug in Edebug.
> > > > > >
> > > > >
> > > > >
> > > > > The immediate trigger appears to be that in `edebug-slow-after' for
> > > > > `flycheck--checker-property-name' the AFTER-INDEX is out of range for
> > > > > the EDEBUG-FREQ-COUNT vector.  I still don't understand why though;
> > > > > there must be some part in edebug that misinstruments these forms.
> > > > > The vector [66 86 129 138 139] is likely a vector of offsets, not
> > > > > frequencies; the vector matches the setter for flycheck-checker-get
> > > > > quite well. So maybe there's an issue with how edebug instruments
> > > > > gv-define-setter?
> > > >
> > > > Yup, looks like this is the root of the issue. Minimal example:
> > > >
> > > > $ cat /tmp/a.el
> > > > (defun foo (b) b)
> > > > (defun my-get (a b) (get a (foo b)))
> > > > (gv-define-setter my-get (x a b) `(setf (get ,a (foo ,b)) ,x))
> > > > (push 'foo (my-get 'foo 'bar))
> > > >
> > > > $ emacs -Q -l edebug -f edebug-all-defuns /tmp/a.el
> > > >
> > > > Then run M-x eval-buffer and hit G three times. Error:
> > > > edebug--display: Args out of range: [33 47 55 60 61], 5
> > > >
> > > > Could the problem here be that to find the instrumentation metadata of
> > > > SYMBOL edebug uses (get SYMBOL 'edebug), and that it doesn't detect
> > > > that the setter for `my-get' is a new entity?
> > >
> > > So it looks more and more like the implementation of
> > > `edebug-read-and-maybe-wrap-form1' generally doesn't support this use
> > > case well at all. If the Edebug spec is `(&define name...)', then it
> > > appears to blindly assume that the form being instrumented is the only
> > > form defining NAME. That's clearly incorrect as NAME can mean
> > > different kinds of entities depending on what the defining macro
> > > happens to define.
> > > I guess for `gv-define-setter' we can work around this by adding
> > > `:name gv-setter' to the edebug specification, but the issue should be
> > > fixed (or at least detected) in Edebug more generally. Also debugging
> > > this is extremely hard because there's no backtrace etc.
> >
> > I've now fixed the gv-setter issue with commit 62cf8f1649, but I'll
> > leave this bug open to track fixes for this class of issues in
> > edebug.el, as well as debuggability improvements.
>
> There are a couple similar bugs in Edebug. For example, there's code
> to ensure that nested named functions (cl-letf etc.) don't clash with
> each other, but that doesn't actually work. For example, edebugging
> the definition
>   (defun foo () (cl-flet ((bar ())) 1))
> results in the messages
>   Edebug: bar
>   Edebug: foo
> which is wrong because "bar" is local, so the symbol should be "foo <at> bar".

However, even that isn't enough because `foo' could contain multiple
non-overlapping definitions of `bar'. So probably this should use a
similar strategy as cl-macrolet, i.e. generate a unique name.

Previous Next

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