failed AVER: (OR (NOT SB-C::ENTRY) (EQ (SB-C::FUNCTIONAL-KIND SB-C::ENTRY) :DELETED))

[Douglas Katzman]

Repro:
(defun foo-node (stuff &optional (pos 0) rule)
  (loop for child in stuff
        do (setf pos (multiple-value-call #'foo-node child pos 42))
        finally (set '*some-var* pos)))

Culprit change is
64364ae28bb06ba0f575dec717c0663673a3def3

[Stas Boukarev (stassats)]

Here's a reduced testcase:

(defun abc (&optional pos)
  (multiple-value-call #'abc pos))

and it's old and wasn't caused by 64364ae28bb06ba0f575dec717c0663673a3def3.

[Alastair Bridgewater (alastair-bridgewater)]

Bisected to a6a12ed609d5467ec43b411283e5b3568fee81df.

[Douglas Katzman (dougk)]

From a user's stance it doesn't matter that a different test case regressed at an earlier commit.
The change I referenced breaks QPX and we'll need that reverted if it can't be fixed before release

Before:
% git checkout 64364ae~1
HEAD is now at b5f0e55... Fix parallel building on older SBCL hosts
% make.sh
...
./run-sbcl.sh
(running SBCL from: .)
This is SBCL 1.3.10.59-b5f0e55, an implementation of ANSI Common Lisp.
* (defun foo-node ...)
* (compile'foo-node) => (VALUES FOO-NODE T NIL)

After:
% git checkout 64364ae
Note: checking out '64364ae'.
% make.sh
...
% ./run-sbcl.sh
(running SBCL from: .)
This is SBCL 1.3.10.60-64364ae, an implementation of ANSI Common Lisp.
[...]
* (defun foo-node ...)
* (compile'foo-node)
debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {10029C6903}>:
    failed AVER:
      (OR (NOT SB-C::ENTRY) (EQ (SB-C::FUNCTIONAL-KIND SB-C::ENTRY) :DELETED))

[Stas Boukarev (stassats)]

I don't want my work to be reverted because of somebody's mistake years ago. You can just as easily patch SBCL to get it to work with QPX.

[Stas Boukarev (stassats)]

f4a4584f89bf5675cad03a89011a01514e2aef1f

[Christophe Rhodes (csr21-cantab)]

Stas Boukarev <email address hidden> writes:

> I don't want my work to be reverted because of somebody's mistake years
> ago. You can just as easily patch SBCL to get it to work with QPX.

Thank you for the fix.

In general, if a code rework causes a regression by exposing an old bug
to code that worked before, even if the bug is not new, I will revert on
the basis that our userbase geneally (not just QPX) is less equipped to
deal with new breakage than we are to delay releasing a new feature into
the wild. I'm glad I don't have to make that call in this case.

Christophe