-REPORTING BUGS
+SBCL uses Launchpad to track bugs. The bug database is available at:
-Bugs can be reported on the help mailing list
- sbcl-help@lists.sourceforge.net
-or on the development mailing list
- sbcl-devel@lists.sourceforge.net
+ https://bugs.launchpad.net/sbcl
-Please include enough information in a bug report that someone reading
-it can reproduce the problem, i.e. don't write
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
-but instead
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
- I compile and load the file
- (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
- (LET ((*PRINT-LENGTH* 4))
- (PRINT X Y)))))
- X Y)
- then at the command line type
- (MAKE-FOO)
- the program loops endlessly instead of printing the object.
+Reporting bugs there requires registering at Launchpad. However, bugs
+can also be reported on the mailing list sbcl-bugs, which is
+moderated but does _not_ require subscribing. Simply send email to
-If you run into a signal related bug, you are getting fatal errors
-such as 'signal N is [un]blocked' or just hangs, and you want to send
-a useful bug report then:
+ sbcl-bugs@lists.sourceforge.net
-- compile sbcl with ldb support (feature :sb-ldb, see
- base-target-features.lisp-expr) and change '#define QSHOW_SIGNAL 0'
- to '#define QSHOW_SIGNAL 1' in src/runtime/runtime.h.
+and the bug will be checked and added to Launchpad by SBCL maintainers.
-- isolate a smallish test case, run it
+Historical note: before Launchpad was adopted this file contained a
+list of currently open bugs. If you run into an SBCL bug number in the
+range 1-431 inclusive, it refers to that list.
-- if it just hangs kill it with sigabrt: kill -ABRT <pidof sbcl>
-
-- print the backtrace from ldb by typing 'ba'
-
-- attach gdb: gdb -p <pidof sbcl> and get backtraces for all threads:
- thread apply all ba
-
-- if multiple threads are in play then still in gdb, try to get Lisp
- backtrace for all threads: 'thread apply all
- call_backtrace_from_fp($ebp, 100)'. Substitute $ebp with $rbp on
- x86-64.
-
-- send a report with the backtraces and the output (both stdout,
- stderr) produced by sbcl
-
-- don't forget to include OS and SBCL version
-
-- if available include info on outcome of the same test with other
- versions of SBCL, OS, ...
-
-
-NOTES:
-
-There is also some information on bugs in the manual page and
-in the TODO file. Eventually more such information may move here.
-
-The gaps in the number sequence belong to old bug descriptions which
-have gone away (typically because they were fixed, but sometimes for
-other reasons, e.g. because they were moved elsewhere).
-
-
-2:
- DEFSTRUCT almost certainly should overwrite the old LAYOUT information
- instead of just punting when a contradictory structure definition
- is loaded. As it is, if you redefine DEFSTRUCTs in a way which
- changes their layout, you probably have to rebuild your entire
- program, even if you know or guess enough about the internals of
- SBCL to wager that this (undefined in ANSI) operation would be safe.
-
-3: "type checking of structure slots"
- a:
- ANSI specifies that a type mismatch in a structure slot
- initialization value should not cause a warning.
-WORKAROUND:
- This one might not be fixed for a while because while we're big
- believers in ANSI compatibility and all, (1) there's no obvious
- simple way to do it (short of disabling all warnings for type
- mismatches everywhere), and (2) there's a good portable
- workaround, and (3) by their own reasoning, it looks as though
- ANSI may have gotten it wrong. ANSI justifies this specification
- by saying
- The restriction against issuing a warning for type mismatches
- between a slot-initform and the corresponding slot's :TYPE
- option is necessary because a slot-initform must be specified
- in order to specify slot options; in some cases, no suitable
- default may exist.
- However, in SBCL (as in CMU CL or, for that matter, any compiler
- which really understands Common Lisp types) a suitable default
- does exist, in all cases, because the compiler understands the
- concept of functions which never return (i.e. has return type NIL).
- Thus, as a portable workaround, you can use a call to some
- known-never-to-return function as the default. E.g.
- (DEFSTRUCT FOO
- (BAR (ERROR "missing :BAR argument")
- :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
- or
- (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
- (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
- (ERROR "missing required argument"))
- (DEFSTRUCT FOO
- (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
- (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
- (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
- Such code should compile without complaint and work correctly either
- on SBCL or on any other completely compliant Common Lisp system.
-
-33:
- And as long as we're wishing, it would be awfully nice if INSPECT could
- also report on closures, telling about the values of the bound variables.
-
- Currently INSPECT and DESCRIBE do show the values, but showing the
- names of the bindings would be even nicer.
-
-35:
- The compiler assumes that any time a function of declared FTYPE
- doesn't signal an error, its arguments were of the declared type.
- E.g. compiling and loading
- (DECLAIM (OPTIMIZE (SAFETY 3)))
- (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DEFUN GAMMA (X) X)
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
- (DEFUN FOO (X)
- (COND ((> (FACTORIAL X) 1.0E6)
- (FORMAT T "too big~%"))
- ((INTEGERP X)
- (FORMAT T "exactly ~S~%" (FACTORIAL X)))
- (T
- (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
- then executing
- (FOO 1.5)
- will cause the INTEGERP case to be selected, giving bogus output a la
- exactly 2.5
- This violates the "declarations are assertions" principle.
- According to the ANSI spec, in the section "System Class FUNCTION",
- this is a case of "lying to the compiler", but the lying is done
- by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
- not by the unexpectedly general definition of FACTORIAL. In any case,
- "declarations are assertions" means that lying to the compiler should
- cause an error to be signalled, and should not cause a bogus
- result to be returned. Thus, the compiler should not assume
- that arbitrary functions check their argument types. (It might
- make sense to add another flag (CHECKED?) to DEFKNOWN to
- identify functions which *do* check their argument types.)
- (Also, verify that the compiler handles declared function
- return types as assertions.)
-
-42:
- The definitions of SIGCONTEXT-FLOAT-REGISTER and
- %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
- supported on FreeBSD because the floating point state is not saved,
- but at least as of FreeBSD 4.0, the floating point state *is* saved,
- so they could be supported after all. Very likely
- SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
-
-61:
- Compiling and loading
- (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
- (FAIL 12)
- then requesting a BACKTRACE at the debugger prompt gives no information
- about where in the user program the problem occurred.
-
- (this is apparently mostly fixed on the SPARC, PPC, and x86 architectures:
- while giving the backtrace the non-x86 systems complains about "unknown
- source location: using block start", but apart from that the
- backtrace seems reasonable. On x86 this is masked by bug 353. See
- tests/debug.impure.lisp for a test case)
-
-64:
- Using the pretty-printer from the command prompt gives funny
- results, apparently because the pretty-printer doesn't know
- about user's command input, including the user's carriage return
- that the user, and therefore the pretty-printer thinks that
- the new output block should start indented 2 or more characters
- rightward of the correct location.
-
-67:
- As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
- and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
- crashes SBCL. In general tracing anything which is used in the
- implementation of TRACE is likely to have the same problem.
-
-78:
- ANSI says in one place that type declarations can be abbreviated even
- when the type name is not a symbol, e.g.
- (DECLAIM ((VECTOR T) *FOOVECTOR*))
- SBCL doesn't support this. But ANSI says in another place that this
- isn't allowed. So it's not clear this is a bug after all. (See the
- e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
- and Pierre Mai.)
-
- (Actually this has changed changed since, and types as above are
- now supported. This may be a bug.)
-
-83:
- RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
- RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
- the mean of the distribution can be systematically O(0.1%) wrong.
- Just increasing R-I-E-B is probably not a good solution, since
- it would decrease efficiency more than is probably necessary. Perhaps
- using some sort of accept/reject method would be better.
-
-85:
- Internally the compiler sometimes evaluates
- (sb-kernel:type/= (specifier-type '*) (specifier-type t))
- (I stumbled across this when I added an
- (assert (not (eq type1 *wild-type*)))
- in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
- in a type context should probably be translated to T, and so it's
- probably wrong to ask whether it's equal to the T type and then (using
- the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
- (I haven't tried to investigate this bug enough to guess whether
- there might be any user-level symptoms.)
-
- In fact, the type system is likely to depend on this inequality not
- holding... * is not equivalent to T in many cases, such as
- (VECTOR *) /= (VECTOR T).
-
-98:
- In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
- CL), out-of-line structure slot setters are horribly inefficient
- whenever the type of the slot is declared, because out-of-line
- structure slot setters are implemented as closures to save space,
- so the compiler doesn't compile the type test into code, but
- instead just saves the type in a lexical closure and interprets it
- at runtime.
- To exercise the problem, compile and load
- (cl:in-package :cl-user)
- (defstruct foo
- (bar (error "missing") :type bar))
- (defvar *foo*)
- (defun wastrel1 (x)
- (loop (setf (foo-bar *foo*) x)))
- (defstruct bar)
- (defvar *bar* (make-bar))
- (defvar *foo* (make-foo :bar *bar*))
- (defvar *setf-foo-bar* #'(setf foo-bar))
- (defun wastrel2 (x)
- (loop (funcall *setf-foo-bar* x *foo*)))
- then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
- use BACKTRACE, to see it's spending all essentially all its time
- in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
- One possible solution would be simply to give up on
- representing structure slot accessors as functions, and represent
- them as macroexpansions instead. This can be inconvenient for users,
- but it's not clear that it's worse than trying to help by expanding
- into a horribly inefficient implementation.
- As a workaround for the problem, #'(SETF FOO) expressions
- can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
-(defmacro efficient-setf-function (place-function-name)
- (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
- ;; a workaround for the problem, encouraging the
- ;; inline expansion of the structure accessor, so
- ;; that the compiler can optimize its type test
- (let ((new-value (gensym "NEW-VALUE-"))
- (structure-value (gensym "STRUCTURE-VALUE-")))
- `(lambda (,new-value ,structure-value)
- (setf (,place-function-name ,structure-value)
- ,new-value))))
- ;; no problem, can just use the ordinary expansion
- `(function (setf ,place-function-name))))
-
-100:
- There's apparently a bug in CEILING optimization which caused
- Douglas Crosher to patch the CMU CL version. Martin Atzmueller
- applied the patches to SBCL and they didn't seem to cause problems
- (as reported sbcl-devel 2001-05-04). However, since the patches
- modify nontrivial code which was apparently written incorrectly
- the first time around, until regression tests are written I'm not
- comfortable merging the patches in the CVS version of SBCL.
-
-108:
- ROOM issues:
-
- a) ROOM works by walking over the heap linearly, instead of
- following the object graph. Hence, it report garbage objects that
- are unreachable. (Maybe this is a feature and not a bug?)
-
- b) ROOM uses MAP-ALLOCATED-OBJECTS to walk the heap, which doesn't
- check all pointers as well as it should, and can hence become
- confused, leading to aver failures. As of 1.0.13.21 these (the
- SAP= aver in particular) should be mostly under control, but push
- ROOM hard enough and it still might croak.
-
-117:
- When the compiler inline expands functions, it may be that different
- kinds of return values are generated from different code branches.
- E.g. an inline expansion of POSITION generates integer results
- from one branch, and NIL results from another. When that inline
- expansion is used in a context where only one of those results
- is acceptable, e.g.
- (defun foo (x)
- (aref *a1* (position x *a2*)))
- and the compiler can't prove that the unacceptable branch is
- never taken, then bogus type mismatch warnings can be generated.
- If you need to suppress the type mismatch warnings, you can
- suppress the inline expansion,
- (defun foo (x)
- #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
- (aref *a1* (position x *a2*)))
- or, sometimes, suppress them by declaring the result to be of an
- appropriate type,
- (defun foo (x)
- (aref *a1* (the integer (position x *a2*))))
-
- This is not a new compiler problem in 0.7.0, but the new compiler
- transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
- more conspicuous. If you don't need performance from these functions,
- and the bogus warnings are a nuisance for you, you can return to
- your pre-0.7.0 state of grace with
- #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
-
- (see also bug 279)
-
-124:
- As of version 0.pre7.14, SBCL's implementation of MACROLET makes
- the entire lexical environment at the point of MACROLET available
- in the bodies of the macroexpander functions. In particular, it
- allows the function bodies (which run at compile time) to try to
- access lexical variables (which are only defined at runtime).
- It doesn't even issue a warning, which is bad.
-
- The SBCL behavior arguably conforms to the ANSI spec (since the
- spec says that the behavior is undefined, ergo anything conforms).
- However, it would be better to issue a compile-time error.
- Unfortunately I (WHN) don't see any simple way to detect this
- condition in order to issue such an error, so for the meantime
- SBCL just does this weird broken "conforming" thing.
-
- The ANSI standard says, in the definition of the special operator
- MACROLET,
- The macro-expansion functions defined by MACROLET are defined
- in the lexical environment in which the MACROLET form appears.
- Declarations and MACROLET and SYMBOL-MACROLET definitions affect
- the local macro definitions in a MACROLET, but the consequences
- are undefined if the local macro definitions reference any
- local variable or function bindings that are visible in that
- lexical environment.
- Then it seems to contradict itself by giving the example
- (defun foo (x flag)
- (macrolet ((fudge (z)
- ;The parameters x and flag are not accessible
- ; at this point; a reference to flag would be to
- ; the global variable of that name.
- ` (if flag (* ,z ,z) ,z)))
- ;The parameters x and flag are accessible here.
- (+ x
- (fudge x)
- (fudge (+ x 1)))))
- The comment "a reference to flag would be to the global variable
- of the same name" sounds like good behavior for the system to have.
- but actual specification quoted above says that the actual behavior
- is undefined.
-
- (Since 0.7.8.23 macroexpanders are defined in a restricted version
- of the lexical environment, containing no lexical variables and
- functions, which seems to conform to ANSI and CLtL2, but signalling
- a STYLE-WARNING for references to variables similar to locals might
- be a good thing.)
-
-135:
- Ideally, uninterning a symbol would allow it, and its associated
- FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
- at least as of sbcl-0.7.0, this isn't the case. Information about
- FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
- essentially in ordinary (non-weak) hash tables keyed by symbols.
- Thus, once a system has an entry in this system, it tends to live
- forever, even when it is uninterned and all other references to it
- are lost.
-
-145:
- a.
- ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
- FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
- COMPLEX implementation didn't deal with this, and hasn't been
- upgraded to do so. (This doesn't seem to be a high priority
- conformance problem, since seems hard to construct useful code
- where it matters.)
-
- [ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests
- report that (COMPLEX RATIO) was failing; still failing on types of
- the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ]
-
- b. (fixed in 0.8.3.43)
-
-146:
- Floating point errors are reported poorly. E.g. on x86 OpenBSD
- with sbcl-0.7.1,
- * (expt 2.0 12777)
- debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
- An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
- No traps are enabled? How can this be?
- It should be possible to be much more specific (overflow, division
- by zero, etc.) and of course the "How can this be?" should be fixable.
-
- See also bugs #45.c and #183
-
-162:
- (reported by Robert E. Brown 2002-04-16)
- When a function is called with too few arguments, causing the
- debugger to be entered, the uninitialized slots in the bad call frame
- seem to cause GCish problems, being interpreted as tagged data even
- though they're not. In particular, executing ROOM in the
- debugger at that point causes AVER failures:
- * (machine-type)
- "X86"
- * (lisp-implementation-version)
- "0.7.2.12"
- * (typep 10)
- ...
- 0] (room)
- ...
- failed AVER: "(SAP= CURRENT END)"
- (Christophe Rhodes reports that this doesn't occur on the SPARC, which
- isn't too surprising since there are many differences in stack
- implementation and GC conservatism between the X86 and other ports.)
-
- (Can't reproduce on x86 linux as of 1.0.20.23 - MGL)
-
- This is probably the same bug as 216
-
-173:
- The compiler sometimes tries to constant-fold expressions before
- it checks to see whether they can be reached. This can lead to
- bogus warnings about errors in the constant folding, e.g. in code
- like
- (WHEN X
- (WRITE-STRING (> X 0) "+" "0"))
- compiled in a context where the compiler can prove that X is NIL,
- and the compiler complains that (> X 0) causes a type error because
- NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
- caused a full WARNING, which made the bug really annoying because then
- COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
- code. Since then the warning has been downgraded to STYLE-WARNING,
- so it's still a bug but at least it's a little less annoying.
-
-183: "IEEE floating point issues"
- Even where floating point handling is being dealt with relatively
- well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
- accrued-exceptions and current-exceptions part of the fp control
- word don't seem to bear much relation to reality. E.g. on
- SPARC/SunOS:
- * (/ 1.0 0.0)
-
- debugger invoked on condition of type DIVISION-BY-ZERO:
- arithmetic error DIVISION-BY-ZERO signalled
- 0] (sb-vm::get-floating-point-modes)
-
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS NIL
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
- 0] abort
- * (sb-vm::get-floating-point-modes)
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS (:INEXACT)
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
-
-188: "compiler performance fiasco involving type inference and UNION-TYPE"
- (time (compile
- nil
- '(lambda ()
- (declare (optimize (safety 3)))
- (declare (optimize (compilation-speed 2)))
- (declare (optimize (speed 1) (debug 1) (space 1)))
- (let ((start 4))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26))
- (print (incf start 28)))
- (let ((start 6))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26)))
- (let ((start 10))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26))))))
-
- [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
- eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
- below, maybe we should be smarter about when to decide a derived
- type is "good enough". ]
-
- This example could be solved with clever enough constraint
- propagation or with SSA, but consider
-
- (let ((x 0))
- (loop (incf x 2)))
-
- The careful type of X is {2k} :-(. Is it really important to be
- able to work with unions of many intervals?
-
-191: "Miscellaneous PCL deficiencies"
- (reported by Alexey Dejneka sbcl-devel 2002-08-04)
- a. DEFCLASS does not inform the compiler about generated
- functions. Compiling a file with
- (DEFCLASS A-CLASS ()
- ((A-CLASS-X)))
- (DEFUN A-CLASS-X (A)
- (WITH-SLOTS (A-CLASS-X) A
- A-CLASS-X))
- results in a STYLE-WARNING:
- undefined-function
- SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
-
- APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
- Mai points out that the declamation of functions is in fact
- incorrect in some cases (most notably for structure
- classes). This means that at present erroneous attempts to use
- WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
- won't get the corresponding STYLE-WARNING.
-
- [much later, in 2006-08] in fact it's no longer erroneous to use
- WITH-SLOTS on structure-classes. However, including :METACLASS
- STRUCTURE-CLASS in the class definition gives a whole bunch of
- function redefinition warnings, so we're still not good to close
- this bug...
-
- c. (fixed in 0.8.4.23)
-
-205: "environment issues in cross compiler"
- (These bugs have no impact on user code, but should be fixed or
- documented.)
- a. Macroexpanders introduced with MACROLET are defined in the null
- lexical environment.
- b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
- the null lexical environment.
- c. The cross-compiler cannot inline functions defined in a non-null
- lexical environment.
-
-207: "poorly distributed SXHASH results for compound data"
- SBCL's SXHASH could probably try a little harder. ANSI: "the
- intent is that an implementation should make a good-faith
- effort to produce hash-codes that are well distributed
- within the range of non-negative fixnums". But
- (let ((hits (make-hash-table)))
- (dotimes (i 16)
- (dotimes (j 16)
- (let* ((ij (cons i j))
- (newlist (push ij (gethash (sxhash ij) hits))))
- (when (cdr newlist)
- (format t "~&collision: ~S~%" newlist))))))
- reports lots of collisions in sbcl-0.7.8. A stronger MIX function
- would be an obvious way of fix. Maybe it would be acceptably efficient
- to redo MIX using a lookup into a 256-entry s-box containing
- 29-bit pseudorandom numbers?
-
-211: "keywords processing"
- a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
- number of keyword arguments.
-
-212: "Sequence functions and circular arguments"
- COERCE, MERGE and CONCATENATE go into an infinite loop when given
- circular arguments; it would be good for the user if they could be
- given an error instead (ANSI 17.1.1 allows this behaviour on the part
- of the implementation, as conforming code cannot give non-proper
- sequences to these functions. MAP also has this problem (and
- solution), though arguably the convenience of being able to do
- (MAP 'LIST '+ FOO '#1=(1 . #1#))
- might be classed as more important (though signalling an error when
- all of the arguments are circular is probably desireable).
-
-213: "Sequence functions and type checking"
- b. MAP, when given a type argument that is SUBTYPEP LIST, does not
- check that it will return a sequence of the given type. Fixing
- it along the same lines as the others (cf. work done around
- sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
- entirely straightforward.
- c. All of these functions will silently accept a type of the form
- (CONS INTEGER *)
- whether or not the return value is of this type. This is
- probably permitted by ANSI (see "Exceptional Situations" under
- ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
- know about this escape clause, so code of the form
- (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
- can erroneously return T.
-
-215: ":TEST-NOT handling by functions"
-
- We should verify that our handling of :TEST-NOT and :TEST is consistent
- for all functions that accept them: that is, signal an error if both
- are specified.
-
- Similarly, a compile-time full warning for calls with both would be good.
-
- We might also consider a compile-time style warning for :TEST-NOT.
-
-216: "debugger confused by frames with invalid number of arguments"
- In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
- leaves the system confused, enough so that (QUIT) no longer works.
- It's as though the process of working with the uninitialized slot in
- the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
- not be the actual problem. (CMU CL 18c doesn't have problems with this.)
-
- (Can't reproduce on x86 linux as of 1.0.20.22 - MGL)
-
- This is probably the same bug as 162
-
-237: "Environment arguments to type functions"
- a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
- UPGRADED-COMPLEX-PART-TYPE now have an optional environment
- argument, but they ignore it completely. This is almost
- certainly not correct.
- b. Also, the compiler's optimizers for TYPEP have not been informed
- about the new argument; consequently, they will not transform
- calls of the form (TYPEP 1 'INTEGER NIL), even though this is
- just as optimizeable as (TYPEP 1 'INTEGER).
-
-242: "WRITE-SEQUENCE suboptimality"
- (observed from clx performance)
- In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
- (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
- (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
- rather than writing the sequence in one go, leading to severe
- performance degradation.
- As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a
- problem in practice. (Fully fixing this would require adding a
- ansi-stream-n-bout slot and associated methods to write a byte
- sequence to ansi-stream, similar to the existing ansi-stream-sout
- slot/functions.)
-
-243: "STYLE-WARNING overenthusiasm for unused variables"
- (observed from clx compilation)
- In sbcl-0.7.14, in the presence of the macros
- (DEFMACRO FOO (X) `(BAR ,X))
- (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
- somewhat surprising style warnings are emitted for
- (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
- ; in: LAMBDA (Y)
- ; (LAMBDA (Y) (FOO Y))
- ;
- ; caught STYLE-WARNING:
- ; The variable Y is defined but never used.
-
-245: bugs in disassembler
- b. On X86 operand size prefix is not recognized.
-
-251:
- (defun foo (&key (a :x))
- (declare (fixnum a))
- a)
-
- does not cause a warning. (BTW: old SBCL issued a warning, but for a
- function, which was never called!)
-
-256:
- Compiler does not emit warnings for
-
- a. (lambda () (svref (make-array 8 :adjustable t) 1))
-
- b. (fixed at some point before 1.0.4.10)
-
- c. (lambda (x)
- (declare (optimize (debug 0)))
- (declare (type vector x))
- (list (fill-pointer x)
- (svref x 1)))
-
-257:
- Complex array type does not have corresponding type specifier.
-
- This is a problem because the compiler emits optimization notes when
- you use a non-simple array, and without a type specifier for hairy
- array types, there's no good way to tell it you're doing it
- intentionally so that it should shut up and just compile the code.
-
- Another problem is confusing error message "asserted type ARRAY
- conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
- compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
-
- The last problem is that when type assertions are converted to type
- checks, types are represented with type specifiers, so we could lose
- complex attribute. (Now this is probably not important, because
- currently checks for complex arrays seem to be performed by
- callees.)
-
-259:
- (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
- warning. Analogous cases with the index and length being equal and
- greater than 0 are warned for; the problem here seems to be that the
- type required for an array reference of this type is (INTEGER 0 (0))
- which is canonicalized to NIL.
-
-260:
- a.
- (let* ((s (gensym))
- (t1 (specifier-type s)))
- (eval `(defstruct ,s))
- (type= t1 (specifier-type s)))
- => NIL, NIL
-
- (fixed in 0.8.1.24)
-
- b. The same for CSUBTYPEP.
-
-262: "yet another bug in inline expansion of local functions"
- During inline expansion of a local function Python can try to
- reference optimized away objects (functions, variables, CTRANs from
- tags and blocks), which later may lead to problems. Some of the
- cases are worked around by forbidding expansion in such cases, but
- the better way would be to reimplement inline expansion by copying
- IR1 structures.
-
-266:
- David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
- behaviour of streams with element-type (SIGNED-BYTE 8). The patch
- looks reasonable, if not obviously correct; however, it caused the
- PPC/Linux port to segfault during warm-init while loading
- src/pcl/std-class.fasl. A workaround patch was made, but it would
- be nice to understand why the first patch caused problems, and to
- fix the cause if possible.
-
-268: "wrong free declaration scope"
- The following code must signal type error:
-
- (locally (declare (optimize (safety 3)))
- (flet ((foo (x &optional (y (car x)))
- (declare (optimize (safety 0)))
- (list x y)))
- (funcall (eval #'foo) 1)))
-
-270:
- In the following function constraint propagator optimizes nothing:
-
- (defun foo (x)
- (declare (integer x))
- (declare (optimize speed))
- (typecase x
- (fixnum "hala")
- (fixnum "buba")
- (bignum "hip")
- (t "zuz")))
-
-273:
- Compilation of the following two forms causes "X is unbound" error:
-
- (symbol-macrolet ((x pi))
- (macrolet ((foo (y) (+ x y)))
- (declaim (inline bar))
- (defun bar (z)
- (* z (foo 4)))))
- (defun quux (z)
- (bar z))
-
- (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
-
-274:
- CLHS says that type declaration of a symbol macro should not affect
- its expansion, but in SBCL it does. (If you like magic and want to
- fix it, don't forget to change all uses of MACROEXPAND to
- MACROEXPAND*.)
-
-275:
- The following code (taken from CLOCC) takes a lot of time to compile:
-
- (defun foo (n)
- (declare (type (integer 0 #.large-constant) n))
- (expt 1/10 n))
-
- (fixed in 0.8.2.51, but a test case would be good)
-
-279: type propagation error -- correctly inferred type goes astray?
- In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
- The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
- &OPTIONAL), not a (INTEGER 1 536870911)
- is emitted when compiling this file:
- (declaim (ftype (function ((integer 0 #.most-positive-fixnum))
- (integer #.most-negative-fixnum 0))
- foo))
- (defun foo (x)
- (- x))
- (defun bar (x)
- (let* (;; Uncomment this for a type mismatch warning indicating
- ;; that the type of (FOO X) is correctly understood.
- #+nil (fs-foo (float-sign (foo x)))
- ;; Uncomment this for a type mismatch warning
- ;; indicating that the type of (ABS (FOO X)) is
- ;; correctly understood.
- #+nil (fs-abs-foo (float-sign (abs (foo x))))
- ;; something wrong with this one though
- (abs-foo (abs (foo x))))
- (declare (type (integer 1 100) abs-foo))
- (print abs-foo)))
-
- (see also bug 117)
-
-283: Thread safety: libc functions
- There are places that we call unsafe-for-threading libc functions
- that we should find alternatives for, or put locks around. Known or
- strongly suspected problems, as of 1.0.3.13: please update this
- bug instead of creating new ones
-
-284: Thread safety: special variables
- There are lots of special variables in SBCL, and I feel sure that at
- least some of them are indicative of potentially thread-unsafe
- parts of the system. See doc/internals/notes/threading-specials
-
-286: "recursive known functions"
- Self-call recognition conflicts with known function
- recognition. Currently cross compiler and target COMPILE do not
- recognize recursion, and in target compiler it can be disabled. We
- can always disable it for known functions with RECURSIVE attribute,
- but there remains a possibility of a function with a
- (tail)-recursive simplification pass and transforms/VOPs for base
- cases.
-
-288: fundamental cross-compilation issues (from old UGLINESS file)
- Using host floating point numbers to represent target floating point
- numbers, or host characters to represent target characters, is
- theoretically shaky. (The characters are OK as long as the characters
- are in the ANSI-guaranteed character set, though, so they aren't a
- real problem as long as the sources don't need anything but that;
- the floats are a real problem.)
-
-289: "type checking and source-transforms"
- a.
- (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
- signals type error.
-
- Our policy is to check argument types at the moment of a call. It
- disagrees with ANSI, which says that type assertions are put
- immediately onto argument expressions, but is easier to implement in
- IR1 and is more compatible to type inference, inline expansion,
- etc. IR1-transforms automatically keep this policy, but source
- transforms for associative functions (such as +), being applied
- during IR1-convertion, do not. It may be tolerable for direct calls
- (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.
-
- b. Another aspect of this problem is efficiency. [x y + z +]
- requires less registers than [x y z + +]. This transformation is
- currently performed with source transforms, but it would be good to
- also perform it in IR1 optimization phase.
-
-290: Alpha floating point and denormalized traps
- In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
- hardware or kernel deficiency: the status of the enable/disable
- denormalized-float traps bit seems to be ambiguous; by the time we
- get to os_restore_fp_control after a trap, denormalized traps seem
- to be enabled. Since we don't want a trap every time someone uses a
- denormalized float, in general, we mask out that bit when we restore
- the control word; however, this clobbers any change the user might
- have made.
-
-297:
- LOOP with non-constant arithmetic step clauses suffers from overzealous
- type constraint: code of the form
- (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
- compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
- (0))). However, an integral value of X should be legal, because
- successive adds of integers to double-floats produces double-floats,
- so none of the type restrictions in the code is violated.
-
-300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
- argument type only after having read a character. This is caused
- with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
- exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
- less error prone to have EXPLICIT-CHECK be a local declaration,
- being put into the definition, instead of an attribute being kept in
- a separate file; maybe also put it into SB-EXT?
-
-301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
- in NOTE-ASSUMED-TYPES
- In sbcl-0.8.7.32, compiling the file
- (defun foo (x y)
- (declare (type integer x))
- (declare (type (vector (or hash-table bit)) y))
- (bletch 2 y))
- (defun bar (x y)
- (declare (type integer x))
- (declare (type (simple-array base (2)) y))
- (bletch 1 y))
- gives the error
- failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
-
-303: "nonlinear LVARs" (aka MISC.293)
- (defun buu (x)
- (multiple-value-call #'list
- (block foo
- (multiple-value-prog1
- (eval '(values :a :b :c))
- (catch 'bar
- (if (> x 0)
- (return-from foo
- (eval `(if (> ,x 1)
- 1
- (throw 'bar (values 3 4)))))))))))
-
- (BUU 1) returns garbage.
-
- The problem is that both EVALs sequentially write to the same LVAR.
-
-306: "Imprecise unions of array types"
-
- a. fixed in SBCL 0.9.15.48
-
- b.(subtypep
- 'array
- `(or
- ,@(loop for x across sb-vm:*specialized-array-element-type-properties*
- collect `(array ,(sb-vm:saetp-specifier x)))))
- => NIL, T (when it should be T, T)
-
-309: "Dubious values for implementation limits"
- (reported by Bruno Haible sbcl-devel "Incorrect value of
- multiple-values-limit" 2004-04-19)
- (values-list (make-list 1000000)), on x86/linux, signals a stack
- exhaustion condition, despite MULTIPLE-VALUES-LIMIT being
- significantly larger than 1000000. There are probably similar
- dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp
- around the same time regarding a call to LIST on sparc with 1000
- arguments) and other implementation limit constants.
-
-314: "LOOP :INITIALLY clauses and scope of initializers"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite, originally by Thomas F. Burdick.
- ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
- ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is
- ;; initialized to the result of evaluating form1. 6.1.7.2 says that
- ;; initially clauses are evaluated in the loop prologue, which precedes all
- ;; loop code except for the initial settings provided by with, for, or as.
- (loop :for x = 0 :then (1+ x)
- :for y = (1+ x) :then (ash y 1)
- :for z :across #(1 3 9 27 81 243)
- :for w = (+ x y z)
- :initially (assert (zerop x)) :initially (assert (= 2 w))
- :until (>= w 100) :collect w)
- Expected: (2 6 15 38)
- Got: ERROR
-
-318: "stack overflow in compiler warning with redefined class"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (defstruct foo a)
- (setf (find-class 'foo) nil)
- (defstruct foo slot-1)
- This used to give a stack overflow from within the printer, which has
- been fixed as of 0.8.16.11. Current result:
- ; caught ERROR:
- ; can't compile TYPEP of anonymous or undefined class:
- ; #<SB-KERNEL:STRUCTURE-CLASSOID FOO>
- ...
- debugger invoked on a TYPE-ERROR in thread 19973:
- The value NIL is not of type FUNCTION.
-
- CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS)
- meant to be enough to delete structure classes from the system?
-
-319: "backquote with comma inside array"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (read-from-string "`#1A(1 2 ,(+ 2 2) 4)")
- gives
- #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
- which probably isn't intentional.
-
-324: "STREAMs and :ELEMENT-TYPE with large bytesize"
- In theory, (open foo :element-type '(unsigned-byte <x>)) should work
- for all positive integral <x>. At present, it only works for <x> up
- to about 1024 (and similarly for signed-byte), so
- (open "/dev/zero" :element-type '(unsigned-byte 1025))
- gives an error in sbcl-0.8.10.
-
-325: "CLOSE :ABORT T on superseding streams"
- Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
- file on disk, even if one existed before opening.
-
- The illegality of this is not crystal clear, as the ANSI dictionary
- entry for CLOSE says that when :ABORT is T superseded files are not
- superseded (ie. the original should be restored), whereas the OPEN
- entry says about :IF-EXISTS :SUPERSEDE "If possible, the
- implementation should not destroy the old file until the new stream
- is closed." -- implying that even though undesirable, early deletion
- is legal. Restoring the original would none the less be the polite
- thing to do.
-
-326: "*PRINT-CIRCLE* crosstalk between streams"
- In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be
- mixed between streams when output operations are intermingled closely
- enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the
- test case below), so that e.g. the references #2# appears on a stream
- with no preceding #2= on that stream to define it (because the #2= was
- sent to another stream).
- (cl:in-package :cl-user)
- (defstruct foo index)
- (defparameter *foo* (make-foo :index 4))
- (defstruct bar)
- (defparameter *bar* (make-bar))
- (defparameter *tangle* (list *foo* *bar* *foo*))
- (defmethod print-object ((foo foo) stream)
- (let ((index (foo-index foo)))
- (format *trace-output*
- "~&-$- emitting FOO ~D, ambient *BAR*=~S~%"
- index *bar*)
- (format stream "[FOO ~D]" index))
- foo)
- (let ((tsos (make-string-output-stream))
- (ssos (make-string-output-stream)))
- (let ((*print-circle* t)
- (*trace-output* tsos)
- (*standard-output* ssos))
- (prin1 *tangle* *standard-output*))
- (let ((string (get-output-stream-string ssos)))
- (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
- ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
- (error "oops: ~S" string)))))
- It might be straightforward to fix this by turning the
- *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
- per-stream slots, but (1) it would probably be sort of messy faking
- up the special variable binding semantics using UNWIND-PROTECT and
- (2) it might be sort of a pain to test that no other bugs had been
- introduced.
-
-328: "Profiling generic functions", transplanted from #241
- (from tonyms on #lisp IRC 2003-02-25)
- In sbcl-0.7.12.55, typing
- (defclass foo () ((bar :accessor foo-bar)))
- (profile foo-bar)
- (unintern 'foo-bar)
- (defclass foo () ((bar :accessor foo-bar)))
- gives the error message
- "#:FOO-BAR already names an ordinary function or a macro."
-
- Problem: when a generic function is profiled, it appears as an ordinary
- function to PCL. (Remembering the uninterned accessor is OK, as the
- redefinition must be able to remove old accessors from their generic
- functions.)
-
-329: "Sequential class redefinition"
- reported by Bruno Haible:
- (defclass reactor () ((max-temp :initform 10000000)))
- (defvar *r1* (make-instance 'reactor))
- (defvar *r2* (make-instance 'reactor))
- (slot-value *r1* 'max-temp)
- (slot-value *r2* 'max-temp)
- (defclass reactor () ((uptime :initform 0)))
- (slot-value *r1* 'uptime)
- (defclass reactor () ((uptime :initform 0) (max-temp :initform 10000)))
- (slot-value *r1* 'max-temp) ; => 10000
- (slot-value *r2* 'max-temp) ; => 10000000 oops...
-
- Possible solution:
- The method effective when the wrapper is obsoleted can be saved
- in the wrapper, and then to update the instance just run through
- all the old wrappers in order from oldest to newest.
-
-336: "slot-definitions must retain the generic functions of accessors"
- reported by Tony Martinez:
- (defclass foo () ((bar :reader foo-bar)))
- (defun foo-bar (x) x)
- (defclass foo () ((bar :reader get-bar))) ; => error, should work
-
- Note: just punting the accessor removal if the fdefinition
- is not a generic function is not enough:
-
- (defclass foo () ((bar :reader foo-bar)))
- (defvar *reader* #'foo-bar)
- (defun foo-bar (x) x)
- (defclass foo () ((bar :initform 'ok :reader get-bar)))
- (funcall *reader* (make-instance 'foo)) ; should be an error, since
- ; the method must be removed
- ; by the class redefinition
-
- Fixing this should also fix a subset of #328 -- update the
- description with a new test-case then.
-
-339: "DEFINE-METHOD-COMBINATION bugs"
- (reported by Bruno Haible via the clisp test suite)
-
- a. Syntax checking laxity (should produce errors):
- i. (define-method-combination foo :documentation :operator)
- ii. (define-method-combination foo :documentation nil)
- iii. (define-method-combination foo nil)
- iv. (define-method-combination foo nil nil
- (:arguments order &aux &key))
- v. (define-method-combination foo nil nil (:arguments &whole))
- vi. (define-method-combination foo nil nil (:generic-function))
- vii. (define-method-combination foo nil nil (:generic-function bar baz))
- viii. (define-method-combination foo nil nil (:generic-function (bar)))
- ix. (define-method-combination foo nil ((3)))
- x. (define-method-combination foo nil ((a)))
-
- b. define-method-combination arguments lambda list badness
- i. &aux args are currently unsupported;
- ii. default values of &optional and &key arguments are ignored;
- iii. supplied-p variables for &optional and &key arguments are not
- bound.
-
- c. (fixed in sbcl-0.9.15.15)
-
-344: more (?) ROOM T problems (possibly part of bug 108)
- In sbcl-0.8.12.51, and off and on leading up to it, the
- SB!VM:MEMORY-USAGE operations in ROOM T caused
- unhandled condition (of type SB-INT:BUG):
- failed AVER: "(SAP= CURRENT END)"
- Several clever people have taken a shot at this without fixing
- it; this time around (before sbcl-0.8.13 release) I (WHN) just
- commented out the SB!VM:MEMORY-USAGE calls until someone figures
- out how to make them work reliably with the rest of the GC.
-
- (Note: there's at least one dubious thing in room.lisp: see the
- comment in VALID-OBJ)
-
-346: alpha backtrace
- In sbcl-0.8.13, all backtraces from errors caused by internal errors
- on the alpha seem to have a "bogus stack frame".
-
-349: PPRINT-INDENT rounding implementation decisions
- At present, pprint-indent (and indeed the whole pretty printer)
- more-or-less assumes that it's using a monospace font. That's
- probably not too silly an assumption, but one piece of information
- the current implementation loses is from requests to indent by a
- non-integral amount. As of sbcl-0.8.15.9, the system silently
- truncates the indentation to an integer at the point of request, but
- maybe the non-integral value should be propagated through the
- pprinter and only truncated at output? (So that indenting by 1/2
- then 3/2 would indent by two spaces, not one?)
-
-352: forward-referenced-class trouble
- reported by Bruno Haible on sbcl-devel
- (defclass c (a) ())
- (setf (class-name (find-class 'a)) 'b)
- (defclass a () (x))
- (defclass b () (y))
- (make-instance 'c)
- Expected: an instance of c, with a slot named x
- Got: debugger invoked on a SIMPLE-ERROR in thread 78906:
- While computing the class precedence list of the class named C.
- The class named B is a forward referenced class.
- The class named B is a direct superclass of the class named C.
-
- [ Is this actually a bug? DEFCLASS only replaces an existing class
- when the class name is the proper name of that class, and in the
- above code the class found by (FIND-CLASS 'A) does not have a
- proper name. CSR, 2006-08-07 ]
-
-353: debugger suboptimalities on x86
- On x86 backtraces for undefined functions start with a bogus stack
- frame, and backtraces for throws to unknown catch tags with a "no
- debug information" frame. These are both due to CODE-COMPONENT-FROM-BITS
- (used on non-x86 platforms) being a more complete solution then what
- is done on x86.
-
- On x86/linux large portions of tests/debug.impure.lisp have been commented
- out as failures. The probable culprit for these problems is in x86-call-context
- (things work fine on x86/freebsd).
-
- More generally, the debugger internals suffer from excessive x86/non-x86
- conditionalization and OAOOMization: refactoring the common parts would
- be good.
-
-356: PCL corruption
- (reported by Bruno Haible)
- After the "layout depth conflict" error, the CLOS is left in a state where
- it's not possible to define new standard-class subclasses any more.
- Test case:
- (defclass prioritized-dispatcher ()
- ((dependents :type list :initform nil)))
- (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class)
- (c2 (eql (find-class 'prioritized-dispatcher))))
- t)
- (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
- ()
- (:metaclass sb-pcl:funcallable-standard-class))
- ;; ERROR, Quit the debugger with ABORT
- (defclass typechecking-reader-class (standard-class)
- ())
- Expected: #<STANDARD-CLASS TYPECHECKING-READER-CLASS>
- Got: ERROR "The assertion SB-PCL::WRAPPERS failed."
-
- [ This test case does not cause the error any more. However,
- similar problems can be observed with
-
- (defclass foo (standard-class) ()
- (:metaclass sb-mop:funcallable-standard-class))
- (sb-mop:finalize-inheritance (find-class 'foo))
- ;; ERROR, ABORT
- (defclass bar (standard-class) ())
- (make-instance 'bar)
- ]
-
-359: wrong default value for ensure-generic-function's :generic-function-class argument
- (reported by Bruno Haible)
- ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says:
- "The remaining arguments are the complete set of keyword arguments
- received by ENSURE-GENERIC-FUNCTION."
- and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS:
- ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not
- supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION."
- This is not the case in SBCL. Test case:
- (defclass my-generic-function (standard-generic-function)
- ()
- (:metaclass sb-pcl:funcallable-standard-class))
- (setf (fdefinition 'foo1)
- (make-instance 'my-generic-function :name 'foo1))
- (ensure-generic-function 'foo1
- :generic-function-class (find-class 'standard-generic-function))
- (class-of #'foo1)
- ; => #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
- (setf (fdefinition 'foo2)
- (make-instance 'my-generic-function :name 'foo2))
- (ensure-generic-function 'foo2)
- (class-of #'foo2)
- Expected: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
- Got: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION>
-
-362: missing error when a slot-definition is created without a name
- (reported by Bruno Haible)
- The MOP says about slot-definition initialization:
- "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument
- is not a symbol which can be used as a variable name. An ERROR is SIGNALled
- if this argument is not supplied."
- Test case:
- (make-instance (find-class 'sb-pcl:standard-direct-slot-definition))
- Expected: ERROR
- Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION NIL>
-
-363: missing error when a slot-definition is created with a wrong documentation object
- (reported by Bruno Haible)
- The MOP says about slot-definition initialization:
- "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled
- if it is not. This argument default to NIL during initialization."
- Test case:
- (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)
- :name 'foo
- :documentation 'not-a-string)
- Expected: ERROR
- Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
-
-370: reader misbehaviour on large-exponent floats
- (read-from-string "1.0s1000000000000000000000000000000000000000")
- causes the reader to attempt to create a very large bignum (which it
- will then attempt to coerce to a rational). While this isn't
- completely wrong, it is probably not ideal -- checking the floating
- point control word state and then returning the relevant float
- (most-positive-short-float or short-float-infinity) or signalling an
- error immediately would seem to make more sense.
-
-372: floating-point overflow not signalled on ppc/darwin
- The following assertions in float.pure.lisp fail on ppc/darwin
- (Mac OS X version 10.3.7):
- (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
- floating-point-overflow))
- (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
- floating-point-overflow)))
- as the SCALE-FLOAT just returns
- #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
- disabled on Darwin for now.
-
-377: Memory fault error reporting
- On those architectures where :C-STACK-IS-CONTROL-STACK is in
- *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
- so we cannot handle the signal directly (as in interrupt_handle_now())
- in the case when the signal comes from some external agent (the user
- using kill(1), or a fault in some foreign code, for instance). As
- of sbcl-0.8.20.20, this is fixed by calling
- arrange_return_to_lisp_function() to a new error-signalling
- function, but as a result the error reporting is poor: we cannot
- even tell the user at which address the fault occurred. We should
- arrange such that arguments can be passed to the function called from
- arrange_return_to_lisp_function(), but this looked hard to do in
- general without suffering from memory leaks.
-
-379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
- See commented-out test-case in debug.impure.lisp.
-
-382: externalization unexpectedly changes array simplicity
- COMPILE-FILE and LOAD
- (defun foo ()
- (let ((x #.(make-array 4 :fill-pointer 0)))
- (values (eval `(typep ',x 'simple-array))
- (typep x 'simple-array))))
- then (FOO) => T, NIL.
-
- Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
- and all array dimension functions.
-
-383: ASH'ing non-constant zeros
- Compiling
- (lambda (b)
- (declare (type (integer -2 14) b))
- (declare (ignorable b))
- (ash (imagpart b) 57))
- on PPC (and other platforms, presumably) gives an error during the
- emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to
- stuff a too-large constant into the immediate field of a PPC
- instruction. Either the VOP should be fixed or the compiler should be
- taught how to transform this case away, paying particular attention
- to side-effects that might occur in the arguments to ASH.
-
-384: Compiler runaway on very large character types
-
- (compile nil '(lambda (x)
- (declare (type (member #\a 1) x))
- (the (member 1 nil) x)))
-
- The types apparently normalize into a very large type, and the compiler
- gets lost in REMOVE-DUPLICATES. Perhaps the latter should use
- a better algorithm (one based on hash tables, say) on very long lists
- when :TEST has its default value?
-
- A simpler example:
-
- (compile nil '(lambda (x) (the (not (eql #\a)) x)))
-
- (partially fixed in 0.9.3.1, but a better representation for these
- types is needed.)
-
-385:
- (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
- (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
- (format nil "~E" 0.01) => "10.e-3" (should be "1.e-2");
- (format nil "~G" 0.01) => "10.e-3" (should be "1.e-2");
-
-386: SunOS/x86 stack exhaustion handling broken
- According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
- stack exhaustion checking (implemented with a write-protected guard
- page) does not work on SunOS/x86.
-
-388:
- (found by Dmitry Bogomolov)
-
- (defclass foo () ((x :type (unsigned-byte 8))))
- (defclass bar () ((x :type symbol)))
- (defclass baz (foo bar) ())
-
- causes error
-
- SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
- (UNSIGNED-BYTE 8).
-
- [ Can't trigger this any more, as of 2006-08-07 ]
-
-389:
- (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
- others)
-
- ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
- specifying whether they're SINGLE or DOUBLE. This is true for types
- computed by the type system itself, but the compiler type derivation
- short-circuits this and constructs non-canonical types. A temporary
- fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
- the right fix is to remove the abstraction violation in the
- compiler's type deriver.
-
-393: Wrong error from methodless generic function
- (DEFGENERIC FOO (X))
- (FOO 1 2)
- gives NO-APPLICABLE-METHOD rather than an argument count error.
-
-396: block-compilation bug
- (let ((x 1))
- (dotimes (y 10)
- (let ((y y))
- (when (funcall (eval #'(lambda (x) (eql x 2))) y)
- (defun foo (z)
- (incf x (incf y z))))))
- (defun bar (z)
- (foo z)
- (values x)))
- (bar 1) => 11, should be 4.
-
-397: SLEEP accuracy
- The more interrupts arrive the less accurate SLEEP's timing gets.
- (time (sb-thread:terminate-thread
- (prog1 (sb-thread:make-thread (lambda ()
- (loop
- (princ #\!)
- (force-output)
- (sb-ext:gc))))
- (sleep 1))))
-
-398: GC-unsafe SB-ALIEN string deporting
- Translating a Lisp string to an alien string by taking a SAP to it
- as done by the :DEPORT-GEN methods for C-STRING and UTF8-STRING
- is not safe, since the Lisp string can move. For example the
- following code will fail quickly on both cheneygc and pre-0.9.8.19
- GENCGC:
-
- (setf (bytes-consed-between-gcs) 4096)
- (define-alien-routine "strcmp" int (s1 c-string) (s2 c-string))
-
- (loop
- (let ((string "hello, world"))
- (assert (zerop (strcmp string string)))))
-
- (This will appear to work on post-0.9.8.19 GENCGC, since
- the GC no longer zeroes memory immediately after releasing
- it after a minor GC. Either enabling the READ_PROTECT_FREE_PAGES
- #define in gencgc.c or modifying the example so that a major
- GC will occasionally be triggered would unmask the bug.)
-
- On cheneygc the only solution would seem to be allocating some alien
- memory, copying the data over, and arranging that it's freed once we
- return. For GENCGC we could instead try to arrange that the string
- from which the SAP is taken is always pinned.
-
- For some more details see comments for (define-alien-type-method
- (c-string :deport-gen) ...) in host-c-call.lisp.
-
-403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
- In sbcl-0.9.13.34,
- (defparameter *c*
- (make-condition 'simple-error
- :format-control "ow... ~S"
- :format-arguments '(#1=(#1#))))
- (setf *print-circle* t *print-level* 4)
- (format nil "~@<~A~:@>" *c*)
- gives
- "ow... (((#)))"
- where I (WHN) believe the correct result is "ow... #1=(#1#)",
- like the result from (PRINC-TO-STRING *C*). The question of
- what the correct result is is complicated by the hairy text in
- the Hyperspec "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
- Other than the difference in its argument, ~@<...~:> is
- exactly the same as ~<...~:> except that circularity detection
- is not applied if ~@<...~:> is encountered at top level in a
- format string.
- But because the odd behavior happens even without the at-sign,
- (format nil "~<~A~:@>" (list *c*)) ; => "ow... (((#)))"
- and because something seemingly similar can happen even in
- PPRINT-LOGICAL-BLOCK invoked directly without FORMAT,
- (pprint-logical-block (*standard-output* '(some nonempty list))
- (format *standard-output* "~A" '#1=(#1#)))
- (which prints "(((#)))" to *STANDARD-OUTPUT*), I don't think
- that the 22.3.5.2 trickiness is fundamental to the problem.
-
- My guess is that the problem is related to the logic around the MODE
- argument to CHECK-FOR-CIRCULARITY, but I haven't reverse-engineered
- enough of the intended meaning of the different MODE values to be
- confident of this.
-
-404: nonstandard DWIMness in LOOP with unportably-ordered clauses
- In sbcl-0.9.13, the code
- (loop with stack = (make-array 2 :fill-pointer 2 :initial-element t)
- for length = (length stack)
- while (plusp length)
- for element = (vector-pop stack)
- collect element)
- compiles without error or warning and returns (T T). Unfortunately,
- it is inconsistent with the ANSI definition of the LOOP macro,
- because it mixes up VARIABLE-CLAUSEs with MAIN-CLAUSEs. Furthermore,
- SBCL's interpretation of the intended meaning is only one possible,
- unportable interpretation of the noncompliant code; in CLISP 2.33.2,
- the code compiles with a warning
- LOOP: FOR clauses should occur before the loop's main body
- and then fails at runtime with
- VECTOR-POP: #() has length zero
- perhaps because CLISP has shuffled the clauses into an
- ANSI-compliant order before proceeding.
-
-406: functional has external references -- failed aver
- Given the following food in a single file
- (eval-when (:compile-toplevel :load-toplevel :execute)
- (defstruct foo3))
- (defstruct bar
- (foo #.(make-foo3)))
- as of 0.9.18.11 the file compiler breaks on it:
- failed AVER: "(NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA))"
- Defining the missing MAKE-LOAD-FORM method makes the error go away.
-
-407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums
- (reported by Ariel Badichi on sbcl-devel 2007-01-09)
- 407a: In sbcl-1.0.1 on Linux x86,
- (defun foo ()
- (loop for n from (expt 2 1024) do
- (handler-case
- (coerce n 'single-float)
- (simple-type-error ()
- (format t "Got here.~%")
- (return-from foo)))))
- (foo)
- causes an infinite loop, where handling the error would be expected.
- 407b: In sbcl-1.0.1 on Linux x86,
- (defun bar ()
- (loop for n from (expt 2 1024) do
- (handler-case
- (format t "~E~%" (coerce n 'single-float))
- (simple-type-error ()
- (format t "Got here.~%")
- (return-from bar)))))
- fails to compile, with
- Too large to be represented as a SINGLE-FLOAT: ...
- from
- 0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...)
- 1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...)
- 2: (SB-KERNEL:%SINGLE-FLOAT ...)
- 3: (SB-C::BOUND-FUNC ...)
- 4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
-
- These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
- type-error at runtime. The question is, should it instead signal a
- floating-point overflow, or return an infinity?
-
-408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
- As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
- (aver (equal (multiple-value-list
- (subtypep '(or (satisfies x) string)
- '(or (satisfies x) integer)))
- '(nil nil)))
- fails. Also, beneath that failure lurks another failure,
- (aver (equal (multiple-value-list
- (subtypep 'string
- '(or (satisfies x) integer)))
- '(nil nil)))
- Having looked at this for an hour or so in sbcl-1.0.2, and
- specifically having looked at the output from
- laptop$ sbcl
- * (let ((x 'string)
- (y '(or (satisfies x) integer)))
- (trace sb-kernel::union-complex-subtypep-arg2
- sb-kernel::invoke-complex-subtypep-arg1-method
- sb-kernel::type-union
- sb-kernel::type-intersection
- sb-kernel::type=)
- (subtypep x y))
- my (WHN) impression is that the problem is that the semantics of TYPE=
- are wrong for what the UNION-COMPLEX-SUBTYPEP-ARG2 code is trying
- to use it for. The comments on the definition of TYPE= probably
- date back to CMU CL and seem to define it as a confusing thing:
- its primary value is something like "certainly equal," and its
- secondary value is something like "certain about that certainty."
- I'm left uncertain how to fix UNION-COMPLEX-SUBTYPEP-ARG2 without
- reducing its generality by removing the TYPE= cleverness. Possibly
- the tempting TYPE/= relative defined next to it might be a
- suitable replacement for the purpose. Probably, though, it would
- be best to start by reverse engineering exactly what TYPE= and
- TYPE/= do, and writing an explanation which is so clear that one
- can see immediately what it's supposed to mean in odd cases like
- (TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet.
-
-409: MORE TYPE SYSTEM PROBLEMS
- Found while investigating an optimization failure for extended
- sequences. The extended sequence type implementation was altered to
- work around the problem, but the fundamental problem remains, to wit:
- (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio))
- (sb-kernel:specifier-type 'single-float))
- returns NIL, NIL on sbcl-1.0.3.
- (probably related to bug #408)
-
-410: read circularities and type declarations
- Consider the definition
- (defstruct foo (a 0 :type (not symbol)))
- followed by
- (setf *print-circle* t) ; just in case
- (read-from-string "#1=#s(foo :a #1#)")
- This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the
- implementation of read circularity, using a symbol as a marker for
- the previously-referenced object.
-
-416: backtrace confusion
-
- (defun foo (x)
- (let ((v "foo"))
- (flet ((bar (z)
- (oops v z)
- (oops z v)))
- (bar x)
- (bar v))))
- (foo 13)
-
- gives the correct error, but the backtrace shows
- 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
- as the second frame.
-
-418: SUBSEQ on lists doesn't support bignum indexes
-
- LIST-SUBSEQ* now has all the works necessary to support bignum indexes,
- but it needs to be verified that changing the DEFKNOWN doesn't kill
- performance elsewhere.
-
- Other generic sequence functions have this problem as well.
-
-419: stack-allocated indirect closure variables are not popped
-
- (defun bug419 (x)
- (multiple-value-call #'list
- (eval '(values 1 2 3))
- (let ((x x))
- (declare (sb-int:truly-dynamic-extent x))
- (flet ((mget (y)
- (+ x y))
- (mset (z)
- (incf x z)))
- (declare (dynamic-extent #'mget #'mset))
- ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset)))))
-
- (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure
-
- Note: as of SBCL 1.0.16.29 this bug no longer affects user code, as
- SB-INT:TRULY-DYNAMIC-EXTENT needs to be used instead of
- DYNAMIC-EXTENT for this to happen. Proper fix for this bug requires
- (Nikodemus thinks) storing the relevant LAMBDA-VARs in a
- :DYNAMIC-EXTENT cleanup, and teaching stack analysis how to deal
- with them.
-
-421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
-
- It seems that on Windows READ-CHAR-NO-HANG hangs if the user
- has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P
- seems to lie if the OS is buffering input for us on Console.)
-
- reported by Elliot Slaughter on sbcl-devel 2008/1/10.
-
-422: out-of-extent return not checked in safe code
-
- (declaim (optimize safety))
- (funcall (catch 't (block nil (throw 't (lambda () (return))))))
-
-behaves ...erratically. Reported by Kevin Reid on sbcl-devel
-2007-07-06. (We don't _have_ to check things like this, but we
-generally try to check returns in safe code, so we should here too.)
-
-424: toplevel closures and *CHECK-CONSISTENCY*
-
- The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true.
-
- (let ((exported-symbols-alist
- (loop for symbol being the external-symbols of :cl
- collect (cons symbol
- (concatenate 'string
- "#"
- (string-downcase symbol))))))
- (defun hyperdoc-lookup (symbol)
- (cdr (assoc symbol exported-symbols-alist))))
-
- (Test-case adapted from CL-PPCRE.)
-
-428: TIMER SCHEDULE-STRESS and PARALLEL-UNSCHEDULE in
- timer.impure.lisp fails
-
- Failure modes vary. Core problem seems to be (?) recursive entry to
- RUN-EXPIRED-TIMERS.
-
-429: compiler hangs
-
- Compiling a file with this contents makes the compiler loop in
- ORDER-UVL-SETS:
-
- (declaim (inline storage))
- (defun storage (x)
- (the (simple-array flt (*)) (unknown x)))
-
- (defun test1 (lumps &key cg)
- (let ((nodes (map 'list (lambda (lump) (storage lump))
- lumps)))
- (setf (aref nodes 0) 2)
- (assert (every #'~= (apply #'concatenate 'list nodes) '(2 3 6 9)))))
-
-431: alien strucure redefinition doesn't work as expected
- fixed in 1.0.21.29
+Refer to User Manual for more details.
projects / sbcl.git / commitdiff