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

[Philipp Stephani]

Am So., 14. Juni 2020 um 18:23 Uhr schrieb 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.

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@bar".