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

[Philipp Stephani]

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.