Type error in compiler: NIL is not of type NUMBER when binding SB-KERNEL::X

Bug #1716061 reported by Paul F. Dietz on 2017-09-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

Found by the random tester. This looks like a pathological function that doesn't return normally and is confusing type propagation. SBCL 1.3.21 on x86 Linux (64 bit).

(compile nil
  '(lambda (b)
     (catch 'ct1
       (flet ((%f (&key (y (throw 'ct1 1)))
  (return-from %f y)))
   (logand (%f) b)
   ))))

==>

The value
  NIL
is not of type
  NUMBER
when binding SB-KERNEL::X
   [Condition of type TYPE-ERROR]

Restarts:
 0: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (SB-KERNEL:TWO-ARG-= NIL -1) [external]
  1: (SB-VM::GENERIC-=)
  2: (SB-C::LEAST-ZERO-BIT NIL)
  3: ((SB-C:DEFTRANSFORM LOGAND) #<SB-C::COMBINATION :FUN #<SB-C::REF :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME LOGAND :TYPE #1=#<SB-KERNEL:FUN-TYPE #> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-F..
  4: (SB-C::IR1-TRANSFORM #<SB-C::COMBINATION :FUN #<SB-C::REF :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME LOGAND :TYPE #1=#<SB-KERNEL:FUN-TYPE #> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION..
  5: (SB-C::IR1-OPTIMIZE-COMBINATION #<SB-C::COMBINATION :FUN #<SB-C::REF :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME LOGAND :TYPE #1=#<SB-KERNEL:FUN-TYPE #> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOB..
  6: (SB-C::IR1-OPTIMIZE-BLOCK #<SB-C::CBLOCK 2 :START c3 {10055DAAA3}>)
  7: (SB-C::IR1-OPTIMIZE #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-0) :REANALYZE T {10055DB513}> NIL)
  8: (SB-C::IR1-OPTIMIZE-UNTIL-DONE #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-0) :REANALYZE T {10055DB513}>)
  9: (SB-C::IR1-PHASES #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-0) :REANALYZE T {10055DB513}>)
 10: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-0) :REANALYZE T {10055DB513}>)
 11: (SB-C::%COMPILE (LAMBDA (B) (CATCH (QUOTE CT1) (FLET # #))) #<SB-C::CORE-OBJECT {10055C2923}> :NAME NIL :PATH (SB-C::ORIGINAL-SOURCE-START 0 0))
 12: ((FLET "WITHOUT-INTERRUPTS-BODY-29" :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
 13: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN SB-C::ACTUALLY-COMPILE) {7FFFF1EB74CB}> #<SB-THREAD:MUTEX "World Lock" owner: #<SB-THREAD:THREAD "main thr..
 14: ((LAMBDA NIL :IN SB-C::ACTUALLY-COMPILE))
 15: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
 16: (SB-C::ACTUALLY-COMPILE NIL (LAMBDA (B) (CATCH (QUOTE CT1) (FLET # #))) #<NULL-LEXENV> NIL NIL NIL)
 17: (SB-C:COMPILE-IN-LEXENV (LAMBDA (B) (CATCH (QUOTE CT1) (FLET # #))) #<NULL-LEXENV> NIL NIL NIL NIL)
 18: (COMPILE NIL (LAMBDA (B) (CATCH (QUOTE CT1) (FLET # #))))
 19: (SB-INT:SIMPLE-EVAL-IN-LEXENV (COMPILE NIL (QUOTE (LAMBDA # #))) #<NULL-LEXENV>)
 --more--(compile nil
  '(lambda (b)
     (catch 'ct1
       (flet ((%f (&key (y (throw 'ct1 1)))
  (return-from %f y)))
   (logand (%f) b)
   ))))

Stas Boukarev (stassats) wrote :

In 215d27f9b42caa488b8370c0f5bb20e11f304415.

Changed in sbcl:
status: New → Fix Committed
Paul F. Dietz (paul-f-dietz) wrote :

Well that was fast.

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

Other bug subscribers