bug#41853: 28.0.50; Peculiar "args out of range" error when using Edebug

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 14. Juni 2020 um 17:48 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am So., 14. Juni 2020 um 17:35 Uhr schrieb Philipp Stephani
> <p.stephani2@gmail.com>:
> >
> > Am So., 14. Juni 2020 um 17:20 Uhr schrieb Philipp Stephani
> > <p.stephani2@gmail.com>:
> > >
> > > Am So., 14. Juni 2020 um 16:23 Uhr schrieb Philipp Stephani
> > > <p.stephani2@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.