Steel Bank Common Lisp

Compiler fails with “The value NIL is not of type SB-C::NODE” on certain combinations of FLET, INLINE, APPLY

Reported by Matthias Benkard on 2013-07-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

The following function definition makes the compiler fail with the error “The value NIL is not of type SB-C::NODE.”

(defun f (x &rest args)
  (flet ((g (&rest args)
           (and x args)))
    (declare (inline g))
    #'g
    (apply #'g args)))

This happens both on SBCL 1.1.8 on Darwin (AMD64) and on 1.0.57.0.debian on GNU/Linux (AMD64).

*features* of 1.1.8 on Darwin:

(:SWANK :ASDF2 :ASDF :ASDF-UNICODE :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :BSD :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS
 :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :DARWIN :DARWIN9-OR-BETTER :FLOAT-EQL-VOPS
 :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :INODE64 :LINKAGE-TABLE
 :LITTLE-ENDIAN :MACH-EXCEPTION-HANDLER :MACH-O :MEMORY-BARRIER-VOPS
 :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR
 :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T
 :PACKAGE-LOCAL-NICKNAMES :RAW-INSTANCE-INIT-VOPS :SB-AFTER-XC-CORE
 :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK
 :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE :SB-XREF-FOR-INTERNALS
 :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :UD2-BREAKPOINTS :UNIX
 :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

*features* of 1.0.57.0.debian:

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

Paul Khuong (pvk) wrote :

Looks like we have an XEP for an &optional entry point that's not marked as being allocated a closure anywhere.

Backtrace:

The value NIL is not of type SB-C::NODE.
   [Condition of type TYPE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread (#<THREAD "new-repl-thread" RUNNING {100887BC53}>)

Backtrace:
  0: (SB-C::NODE-HOME-LAMBDA NIL) [tl,external]
  1: ((LABELS SB-C::FLOOD :IN SB-C::CLOSE-OVER) #<SB-C::PHYSENV :LAMBDA #<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::XEP (SB-C::LOCAL-INLINE (FLET G :IN F))) :KIND :EXTERNAL :TYPE #<..
  2: ((LABELS SB-C::FLOOD :IN SB-C::CLOSE-OVER) #<SB-C::PHYSENV :LAMBDA #<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::&MORE-PROCESSOR (SB-C::LOCAL-INLINE (FLET G :IN F))) :KIND :OPTIO..
  3: ((LABELS SB-C::FLOOD :IN SB-C::CLOSE-OVER) #<SB-C::PHYSENV :LAMBDA #<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::LOCAL-INLINE (FLET G :IN F)) :KIND :OPTIONAL :TYPE #<SB-KERNEL:BU..
  4: (SB-C::CLOSE-OVER #<SB-C::LAMBDA-VAR :%SOURCE-NAME X {100650AAE3}> #<SB-C::PHYSENV :LAMBDA #<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::LOCAL-INLINE (FLET G :IN F)) :KIND :OPTIO..
  5: (SB-C::%ADD-LAMBDA-VARS-TO-CLOSURES #<SB-C::CLAMBDA :%SOURCE-NAME F :%DEBUG-NAME NIL :KIND :OPTIONAL :TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)> :WHERE-FROM :DEFINED :VARS (X ARGS #:REST..
  6: (SB-C::ADD-LAMBDA-VARS-AND-LET-VARS-TO-CLOSURES #<SB-C::CLAMBDA :%SOURCE-NAME F :%DEBUG-NAME NIL :KIND :OPTIONAL :TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)> :WHERE-FROM :DEFINED :VARS (X..
  7: (SB-C::PHYSENV-ANALYZE #<SB-C:COMPONENT :NAME (FLET G :IN F) {1006542363}>)
  8: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (FLET G :IN F) {1006542363}>)
  9: (SB-C::%COMPILE (SB-INT:NAMED-LAMBDA F (X &REST ARGS) (BLOCK F (FLET ((G (&REST ARGS) (AND X ARGS))) (DECLARE (INLINE G)) (FUNCTION G) (APPLY (FUNCTION G) ARGS)))) #<SB-C::CORE-OBJECT > :NAME NIL :PAT..

Paul Khuong (pvk) on 2013-07-20
Changed in sbcl:
status: New → Triaged
importance: Undecided → Medium
Paul Khuong (pvk) wrote :

The attached patch looks semi-sane. It seems to me the issue with inlining is that we create a hacked-up copy of the CLAMBDA (without going through full IR1 conversion of a FUNCTION form that'll %allocate-closure), but end up leaving the copy in a :FULL mv-call, and then tons of invariants are lost. The patch is incredibly kludgey and detects when a multiple value combination would not be converted into a MV-LET, and stops before the inlined copy is patched in.

Thoughts?

(This seems to be a common pattern for inlining-related bugs.)

Paul F. Dietz (paul-dietz) wrote :

I think the random tester was popping up bugs like this some years ago. Is this is duplicate of some existing bug?

Paul Khuong (pvk) wrote :

Git blame shows a similar issue may have been fixed in 0.8.4.11 (https://github.com/pkhuong/sbcl/commit/11f02398a1a9ccbde847c82fd233e8378e45c29c). That's a different problem.

A text search on launchpad didn't reveal anything promising.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers