Steel Bank Common Lisp

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

Reported by Christophe on 2012-08-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
High
Unassigned

Bug Description

Tested successively with SBCL 1.0.56, 1.0.57 and finally 1.0.57.66-5783625 (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

*FEATURES*
*
(:QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ASDF-UNICODE :ANSI-CL
 :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE
 :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :OS-PROVIDES-POLL
 :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-SUSECONDS-T :OS-PROVIDES-BLKSIZE-T
 :OS-PROVIDES-PUTWC :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :LITTLE-ENDIAN
 :LINKAGE-TABLE :MULTIPLY-HIGH-VOPS :MEMORY-BARRIER-VOPS :INLINE-CONSTANTS
 :CYCLE-COUNTER :ALIEN-CALLBACKS :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-CLOSURES :RAW-INSTANCE-INIT-VOPS
 :UNWIND-TO-FRAME-AND-CALL-VOP :COMPARE-AND-SWAP-VOPS :C-STACK-IS-CONTROL-STACK
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :GENCGC :LARGEFILE :SB-FUTEX :SB-THREAD
 :LINUX :ELF :UNIX :X86)

During the compilation of cl-ledger (commit c380be), I encountered the following error
in file "core/valexpr.lisp" while compiling READ-VALUE-TERM
(see https://github.com/jwiegley/cl-ledger/blob/master/core/valexpr.lisp#L47) :

    failed AVER:
      (ZEROP (HASH-TABLE-COUNT (FASL-OUTPUT-PATCH-TABLE FASL-OUTPUT)))

To reproduce the bug, assuming quicklisp is installed :

cd /tmp
git clone git://github.com/jwiegley/cl-ledger.git
ln -s /tmp/cl-ledger ~/quicklisp/local-projects/
sbcl
* (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 :

  0: (SB-INT:BUG "~@<failed AVER: ~2I~_~A~:>" (ZEROP (HASH-TABLE-COUNT (SB-FASL::FASL-OUTPUT-PATCH-TABLE SB-FASL:FASL-OUTPUT))))
  1: (SB-IMPL::%FAILED-AVER (ZEROP (HASH-TABLE-COUNT (SB-FASL::FASL-OUTPUT-PATCH-TABLE SB-FASL:FASL-OUTPUT))))
  2: (SB-FASL:CLOSE-FASL-OUTPUT #<SB-FASL:FASL-OUTPUT "/tmp/fileV19r5N.fasl"> NIL)
  3: ((FLET #:CLEANUP-FUN-102264 :IN COMPILE-FILE))[:CLEANUP]
  4: (COMPILE-FILE "/tmp/fileV19r5N" :OUTPUT-FILE NIL :VERBOSE NIL :PRINT NIL :EXTERNAL-FORMAT :UTF-8 :TRACE-FILE NIL :BLOCK-COMPILE NIL :EMIT-CFASL NIL)
...

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)
  x)

(defun test ()
  (list
   (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