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
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
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.

Revision history for this message
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
Revision history for this message
Lutz Euler (lutz-euler) wrote :

Might this be a duplicate of #504121?

Revision history for this message
Stas Boukarev (stassats) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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)
Changed in sbcl:
status: Triaged → In Progress
assignee: nobody → Paul Khuong (pvk)
Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.