assertion fails on compilation in cl-ledger (%FAILED-AVER (ZEROP (HASH-TABLE-COUNT (SB-FASL::FASL-OUTPUT-PATCH-TABLE FASL-OUTPUT))))

Bug #1035721 reported by Christophe on 2012-08-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Tested successively with SBCL 1.0.56, 1.0.57 and finally (with the same result each time.)

$ uname -a
Linux inspiron 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:35:26 UTC 2012 i686 GNU/Linux


During the compilation of cl-ledger (commit c380be), I encountered the following error
in file "core/valexpr.lisp" while compiling READ-VALUE-TERM
(see :

    failed AVER:

To reproduce the bug, assuming quicklisp is installed :

cd /tmp
git clone git://
ln -s /tmp/cl-ledger ~/quicklisp/local-projects/
* (ql:quickload "cl-ledger")

Also, under the Slime environment, calling slime-compile-defun on READ-VALUE-TERM also triggers this bug.
This gives the following backtrace, which references SB-IMPL:CLOSE-FASL-OUTPUT :


I am not the author of the original source code and I have difficulties further reducing the test case.
I will report this bug to John Wiegley as well, so that he can investigate it if he can.

Stas Boukarev (stassats) wrote :

Reduced test-case:
(declaim (inline call))
(defun call (function)
  (lambda (x)
    (funcall function x)))

(declaim (inline identity-))
(defun identity- (x)

(defun test ()
   (call #'identity-)
   (lambda (x)
        (identity- x))))

Changed in sbcl:
status: New → Triaged
importance: Undecided → High
Lutz Euler (lutz-euler) wrote :

Might this be a duplicate of #504121?

Stas Boukarev (stassats) wrote :

Possibly. Another point is that it compiles successfully with safety other than 1.

Lutz Euler (lutz-euler) wrote :

This bug is marked as a duplicate of #504121.
#504121 has been fixed with f980e90c5539626c007de121278e66acdb91d37c, but the test case from comment #1 still fails: failed AVER: (ZEROP (HASH-TABLE-COUNT (CORE-OBJECT-PATCH-TABLE OBJECT))
This is understandable as the test case doesn't have bad local calls, which #504121 is about.
I am therefore removing the duplicate link.

Paul Khuong (pvk) wrote :

That bug is actually simpler: we tried to dump a reference to a closure for an inlined (i.e. toplevel) function. It looks like a ton of invariants are broken there, but the tiny patch attached seems to DTRT. I'll apply if there aren't objections or questions by tomorrow.

Paul Khuong (pvk) wrote :

Also, ISTM we should make sure there's an XEP for any toplevel functional that appears in value position.

Paul Khuong (pvk) on 2013-05-21
Changed in sbcl:
status: Triaged → In Progress
assignee: nobody → Paul Khuong (pvk)
Paul Khuong (pvk) wrote :

Fixed in 46602bb (Evaluate global inline functions via their fdefinition).

Changed in sbcl:
status: In Progress → Fix Committed
assignee: Paul Khuong (pvk) → nobody
Christophe (junke-christophe) wrote :

This solved the issue that I originally reported, thanks.

Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers