When I bind sb-c::*max-optimize-iterations* to a smaller value, I get new errors. Is this a valid way to test?

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

Bug Description

Given that increasing sb-c::*max-optimize-iterations* made a previous bug go away, I tried decreasing that variable to see if new failures could be induced. Is this a valid bug?

(let ((sb-c::*max-optimize-iterations* 1))
 (eval '(lambda (a b)
  (declare (type fixnum a b))
  (declare (optimize (debug 3)))
  (elt '(167992664 119771479)
       (max 0
            (catch 'ct2
              (if (typep b '(integer -52))
                  a
                  0)))))))

==>

failed AVER: (NOT (EQ SB-KERNEL:CTYPE SB-KERNEL:*WILD-TYPE*))
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

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

Backtrace:
  0: (SB-INT:BUG "~@<failed AVER: ~2I~_~S~:>" (NOT (EQ SB-KERNEL:CTYPE SB-KERNEL:*WILD-TYPE*)))
  1: (SB-IMPL::%FAILED-AVER (NOT (EQ SB-KERNEL:CTYPE SB-KERNEL:*WILD-TYPE*)))
  2: (SB-C::CAST-CHECK-TYPES #<SB-ALIEN:CAST :%TYPE-CHECK NIL :VALUE #<SB-C::LVAR 1 {1004268233}> :ASSERTED-TYPE #<SB-KERNEL:UNION-TYPE LIST> :TYPE-TO-CHECK #<SB-KERNEL:NAMED-TYPE *> {1004243703}>)
  3: (SB-C::GENERATE-TYPE-CHECKS #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-3) :REANALYZE T {1004240713}>)
  4: (SB-C::IR1-PHASES #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-BLOCK-3) :REANALYZE T {1004240713}>)
  5: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (SB-C::ESCAPE-FUN #:EXIT-

Stas Boukarev (stassats) wrote :

This was caused by the previous fix, so maybe it's a good way to check for problems.

Changed in sbcl:
status: New → Fix Committed
Stas Boukarev (stassats) wrote :

In eefd7e616e53f76747efb06ae899bb214513f5f7.

Paul F. Dietz (paul-f-dietz) wrote :

Yes, this showed up very rapidly in the random tester, with a size parameter as small as 10 (normally I use size up to 1000).

Stas Boukarev (stassats) on 2017-12-29
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