X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=HEAD;hp=a0320322d14b6c7f569d012a47ac7b73d3434fd8;hpb=f5522c7149744e4faf34313b18d0d3588d2a9d98;p=sbcl.git diff --git a/BUGS b/BUGS index a032032..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,1670 +1,17 @@ -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 + sbcl-bugs@lists.sourceforge.net -NOTES: +and the bug will be checked and added to Launchpad by SBCL maintainers. -There is also some information on bugs in the manual page and -in the TODO file. Eventually more such information may move here. +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. -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) - -201: "Incautious type inference from compound types" - a. (reported by APD sbcl-devel 2002-09-17) - (DEFUN FOO (X) - (LET ((Y (CAR (THE (CONS INTEGER *) X)))) - (SETF (CAR X) NIL) - (FORMAT NIL "~S IS ~S, Y = ~S" - (CAR X) - (TYPECASE (CAR X) - (INTEGER 'INTEGER) - (T '(NOT INTEGER))) - Y))) - - (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" - - b. - * (defun foo (x) - (declare (type (array * (4 4)) x)) - (let ((y x)) - (setq x (make-array '(4 4))) - (adjust-array y '(3 5)) - (= (array-dimension y 0) (eval `(array-dimension ,y 0))))) - FOO - * (foo (make-array '(4 4) :adjustable t)) - NIL - -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 - -235: "type system and inline expansion" - a. - (declaim (ftype (function (cons) number) acc)) - (declaim (inline acc)) - (defun acc (c) - (the number (car c))) - - (defun foo (x y) - (values (locally (declare (optimize (safety 0))) - (acc x)) - (locally (declare (optimize (safety 3))) - (acc y)))) - - (foo '(nil) '(t)) => NIL, T. - - As of 0.9.15.41 this seems to be due to ACC being inlined only once - inside FOO, which results in the second call reusing the FUNCTIONAL - resulting from the first -- which doesn't check the type. - -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. - ;; - ;; 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: - ; # - ... - 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 )) should work - for all positive integral . At present, it only works for 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: # - 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) - ; => # - (setf (fdefinition 'foo2) - (make-instance 'my-generic-function :name 'foo2)) - (ensure-generic-function 'foo2) - (class-of #'foo2) - Expected: # - Got: # - -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: # - -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: # - -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 , 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.