X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=a6c4b66e040824da2fc76e101f92940e8412c6d3;hp=527b0538568e88450413f09ccc06adb28eaa487d;hpb=711f965c40c13172cbc4b4dd381e6f638a1d6c34;p=sbcl.git diff --git a/BUGS b/BUGS index 527b053..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,1096 +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). - - -KNOWN BUGS OF NO SPECIAL CLASS: - -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. - - b: &AUX argument in a boa-constructor without a default value means - "do not initilize this slot" and does not cause type error. But - an error may be signalled at read time and it would be good if - SBCL did it. - - c: Reading of not initialized slot sometimes causes SEGV (for inline - accessors it is fixed, but out-of-line still do not perform type - check). - - d: - (declaim (optimize (safety 3) (speed 1) (space 1))) - (defstruct foo - x y) - (defstruct (stringwise-foo (:include foo - (x "x" :type simple-string) - (y "y" :type simple-string)))) - (defparameter *stringwise-foo* - (make-stringwise-foo)) - (setf (foo-x *stringwise-foo*) 0) - (defun frob-stringwise-foo (sf) - (aref (stringwise-foo-x sf) 0)) - (frob-stringwise-foo *stringwise-foo*) - SEGV. - -7: - The "compiling top-level form:" output ought to be condensed. - Perhaps any number of such consecutive lines ought to turn into a - single "compiling top-level forms:" line. - -11: - It would be nice if the - caught ERROR: - (during macroexpansion) - said what macroexpansion was at fault, e.g. - caught ERROR: - (during macroexpansion of IN-PACKAGE, - during macroexpansion of DEFFOO) - -19: - (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep.. -- WHN) - (FORMAT NIL "~,1G" 1.4) => "1. " - (FORMAT NIL "~3,1G" 1.4) => "1. " - -27: - Sometimes (SB-EXT:QUIT) fails with - Argh! maximum interrupt nesting depth (4096) exceeded, exiting - Process inferior-lisp exited abnormally with code 1 - I haven't noticed a repeatable case of this yet. - -32: - The printer doesn't report closures very well. This is true in - CMU CL 18b as well: - (PRINT #'CLASS-NAME) - gives - # - It would be nice to make closures have a settable name slot, - and make things like DEFSTRUCT and FLET, which create closures, - set helpful values into this slot. - -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. - -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. - -45: - a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is - bogus, and should probably be 1.4012985e-45. In SBCL, - (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller - than LEAST-POSITIVE-SHORT-FLOAT. Similar problems - exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, - and LEAST-NEGATIVE-LONG-FLOAT. - c: Many expressions generate floating infinity on x86/Linux: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. sbcl-0.7.0.5 - on x86/Linux generates the infinities instead. That might or - might not be conforming behavior, but it's also inconsistent, - which is almost certainly wrong. (Inconsistency: (/ 1 0.0) - should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0) - generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0) - signals an error. - d: (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) - don't give the right behavior. - -46: - type safety errors reported by Peter Van Eynde July 25, 2000: - k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - -60: - The debugger LIST-LOCATIONS command doesn't work properly. - (How should it work properly?) - -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. - -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. - -75: - As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, - ANSI says that WITH-OUTPUT-TO-STRING should have a keyword - :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for - WITH-OUTPUT-TO-STRING. - -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.) - -79: - as pointed out by Dan Barlow on sbcl-devel 2000-07-02: - The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses - an easily guessable temporary filename in a way which might open - applications using LOAD-FOREIGN to hijacking by malicious users - on the same machine. Incantations for doing this safely are - floating around the net in various "how to write secure programs - despite Unix" documents, and it would be good to (1) fix this in - LOAD-FOREIGN, and (2) hunt for any other code which uses temporary - files and make it share the same new safe logic. - - (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to - make the temporary filename less easily guessable) - -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). - -94a: - Inconsistencies between derived and declared VALUES return types for - DEFUN aren't checked very well. E.g. the logic which successfully - catches problems like - (declaim (ftype (function (fixnum) float) foo)) - (defun foo (x) - (declare (type integer x)) - (values x)) ; wrong return type, detected, gives warning, good! - fails to catch - (declaim (ftype (function (t) (values t t)) bar)) - (defun bar (x) - (values x)) ; wrong number of return values, no warning, bad! - The cause of this is seems to be that (1) the internal function - VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its - arguments symmetrically, and (2) when the type checking code was - written back when when SBCL's code was still CMU CL, the intent - was that this case - (declaim (ftype (function (t) t) bar)) - (defun bar (x) - (values x x)) ; wrong number of return values; should give warning? - not be warned for, because a two-valued return value is considered - to be compatible with callers who expects a single value to be - returned. That intent is probably not appropriate for modern ANSI - Common Lisp, but fixing this might be complicated because of other - divergences between auld-style and new-style handling of - multiple-VALUES types. (Some issues related to this were discussed - on cmucl-imp at some length sometime in 2000.) - -95: - The facility for dumping a running Lisp image to disk gets confused - when run without the PURIFY option, and creates an unnecessarily large - core file (apparently representing memory usage up to the previous - high-water mark). Moreover, when the file is loaded, it confuses the - GC, so that thereafter memory usage can never be reduced below that - level. - -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: - (TIME (ROOM T)) reports more than 200 Mbytes consed even for - a clean, just-started SBCL system. And it seems to be right: - (ROOM T) can bring a small computer to its knees for a *long* - time trying to GC afterwards. Surely there's some more economical - way to implement (ROOM T). - -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.. - -118: - as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: - (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) - (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T - when of course it should be NIL. (He says it only fails for X86, - not SPARC; dunno about Alpha.) - - Also, "the same problem exists for LONG-FLOAT-EPSILON, - DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though - for the -negative- the + is replaced by a - in the test)." - - Raymond Toy comments that this is tricky on the X86 since its FPU - uses 80-bit precision internally. - -120b: - Even in sbcl-0.pre7.x, which is supposed to be free of the old - non-ANSI behavior of treating the function return type inferred - from the current function definition as a declaration of the - return type from any function of that name, the return type of NIL - is attached to FOO in 120a above, and used to optimize code which - calls FOO. - -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.) - -125: - (as reported by Gabe Garza on cmucl-help 2001-09-21) - (defvar *tmp* 3) - (defun test-pred (x y) - (eq x y)) - (defun test-case () - (let* ((x *tmp*) - (func (lambda () x))) - (print (eq func func)) - (print (test-pred func func)) - (delete func (list func)))) - Now calling (TEST-CASE) gives output - NIL - NIL - (#) - Evidently Python thinks of the lambda as a code transformation so - much that it forgets that it's also an object. - -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. - -141: "pretty printing and backquote" - a. - * '``(FOO ,@',@S) - ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - - b. - * (write '`(, .ala.) :readably t :pretty t) - `(,.ALA.) - - (note the space between the comma and the point) - -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - -145: - 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.) - -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 - -148: - In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file - (in-package :cl-user) - (defvar *thing*) - (defvar *zoom*) - (defstruct foo bar bletch) - (defun %zeep () - (labels ((kidify1 (kid) - ) - (kid-frob (kid) - (if *thing* - (setf sweptm - (m+ (frobnicate kid) - sweptm)) - (kidify1 kid)))) - (declare (inline kid-frob)) - (map nil - #'kid-frob - (the simple-vector (foo-bar perd))))) - fails with - debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type SB-C::NODE. - The location of this failure has moved around as various related - issues were cleaned up. As of sbcl-0.7.1.9, it occurs in - NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE. - - (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline - expand KID-FROB into %ZEEP. Having partially done it, it sees a call - of KIDIFY1, which already does not exist. So it gives up on - expansion, leaving garbage consisting of infinished blocks of the - partially converted function.) - - (due to reordering of the compiler this example is compiled - successfully by 0.7.14, but the bug probably remains) - -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.) - -167: - In sbcl-0.7.3.11, compiling the (illegal) code - (in-package :cl-user) - (defmethod prove ((uustk uustk)) - (zap ((frob () nil)) - (frob))) - gives the (not terribly clear) error message - ; caught ERROR: - ; (during macroexpansion of (DEFMETHOD PROVE ...)) - ; can't get template for (FROB NIL NIL) - The problem seems to be that the code walker used by the DEFMETHOD - macro is unhappy with the illegal syntax in the method body, and - is giving an unclear error message. - -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)))))) - - This example could be solved with clever enough constraint - propagation or with SSA, but consider - - (let ((x 0)) - (loop (if (random-boolean) - (incf x 2) - (incf x 5)))) - - The careful type of X is {2k+5n} :-(. Is it really important to be - able to work with unions of many intervals? - -190: "PPC/Linux pipe? buffer? bug" - In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs - on the PPC/Linux platform, waiting for a zombie env process. This - is a classic symptom of buffer filling and deadlock, but it seems - only sporadically reproducible. - -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. - c. the examples in CLHS 7.6.5.1 (regarding generic function lambda - lists and &KEY arguments) do not signal errors when they should. - -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. - -206: ":SB-FLUID feature broken" - (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) - Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks - the build. - -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. - e. Compiling - - (flet ((foo (&key y) (list y))) - (list (foo :y 1 :y 2))) - - issues confusing message - - ; in: LAMBDA NIL - ; (FOO :Y 1 :Y 2) - ; - ; caught STYLE-WARNING: - ; The variable #:G15 is defined but never used. - -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" - a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with - various complicated, though recognizeable, CONS types [e.g. - (CONS * (CONS * NULL)) - which according to ANSI should be recognized] (and, in SAFETY 3 - code, should return a list of LENGTH 2 or signal an error) - 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. - -214: - SBCL 0.6.12.43 fails to compile - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (flet ((foo (&key (x :vx x-p)) (list x x-p))) - (foo 1 2))) - - or a more simple example: - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) - -215: ":TEST-NOT handling by functions" - a. FIND and POSITION currently signal errors when given non-NIL for - both their :TEST and (deprecated) :TEST-NOT arguments, but by - ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2 - means that the effect is "unpredictable but harmless". It's not - clear what that actually means; it may preclude conforming - implementations from signalling errors. - b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument - when conflict occurs. As a quality of implementation issue, it - might be preferable to treat :TEST and :TEST-NOT as being in some - sense the same &KEY, and effectively take the first test function in - the argument list. - c. Again, a quality of implementation issue: it would be good to issue a - STYLE-WARNING at compile-time for calls with :TEST-NOT, and a - WARNING for calls with both :TEST and :TEST-NOT; possibly this - latter should be WARNed about at execute-time too. - -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.) - -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) - - Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. - - (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate. Similar - problems exist with VALUES-TYPE-INTERSECTION.) - -220: - Sbcl 0.7.9 fails to compile - - (multiple-value-call #'list - (the integer (helper)) - nil) - - Type check for INTEGER, the result of which serves as the first - argument of M-V-C, is inserted after evaluation of NIL. So arguments - of M-V-C are pushed in the wrong order. As a temporary workaround - type checking was disabled for M-V-Cs in 0.7.9.13. A better solution - would be to put the check between evaluation of arguments, but it - could be tricky to check result types of PROG1, IF etc. - -233: bugs in constraint propagation - a. - (defun foo (x) - (declare (optimize (speed 2) (safety 3))) - (let ((y 0d0)) - (values - (the double-float x) - (setq y (+ x 1d0)) - (setq x 3d0) - (quux y (+ y 2d0) (* y 3d0))))) - (foo 4) => segmentation violation - - (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS) - (see also bug 236) - - b. - (declaim (optimize (speed 2) (safety 3))) - (defun foo (x y) - (if (typep (prog1 x (setq x y)) 'double-float) - (+ x 1d0) - (+ x 2))) - (foo 1d0 5) => segmentation violation - -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. - -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). - -238: "REPL compiler overenthusiasm for CLOS code" - From the REPL, - * (defclass foo () ()) - * (defmethod bar ((x foo) (foo foo)) (call-next-method)) - causes approximately 100 lines of code deletion notes. Some - discussion on this issue happened under the title 'Three "interesting" - bugs in PCL', resulting in a fix for this oververbosity from the - compiler proper; however, the problem persists in the interactor - because the notion of original source is not preserved: for the - compiler, the original source of the above expression is (DEFMETHOD - BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the - compiler gets its hands on the code needing compilation from the REPL, - it has been macroexpanded several times. - - A symptom of the same underlying problem, reported by Tony Martinez: - * (handler-case - (with-input-from-string (*query-io* " no") - (yes-or-no-p)) - (simple-type-error () 'error)) - ; in: LAMBDA NIL - ; (SB-KERNEL:FLOAT-WAIT) - ; - ; note: deleting unreachable code - ; compilation unit finished - ; printed 1 note - -241: "DEFCLASS mysteriously remembers uninterned accessor names." - (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." - So it's somehow checking the uninterned old accessor name instead - of the new requested accessor name, which seems broken to me (WHN). - -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. - -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 - a. On X86 an immediate operand for IMUL is printed incorrectly. - b. On X86 operand size prefix is not recognized. - -248: "reporting errors in type specifier syntax" - (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type - specifier". - -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. (lambda (x) - (list (let ((y (the real x))) - (unless (floatp y) (error "")) - y) - (integer-length x))) - - 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. - -258: "TYPE-ERROR when recursive LABELS function is declared INLINE" - The compiler does emit a helpful - ; note: couldn't inline expand because expansion calls this - ; LET-converted local function: - ; "LABELS COMMON-LISP-USER::C.FROB" - but still shouldn't fail with a TYPE-ERROR - The value NIL is not of type SB-C::NODE. - when compiling - (cl:in-package :cl-user) - (declaim (optimize (safety 3) (speed 2) (space 1))) - (defvar *foo*) - (defvar *bar*) - (defun u-b-sra (x r ad0 &optional ad1 &rest ad-list) - (labels ((c.frob (c0) - (let () - (when *foo* - (vector-push-extend c0 *bar*)))) - (ad.frob (ad) - (if *foo* - (map nil #'ad.frob (the (vector t) *bar*)) - (dolist (b *bar*) - (c.frob b))))) - (declare (inline c.frob ad.frob)) ; 'til DYNAMIC-EXTENT - (ad.frob ad0))) - -DEFUNCT CATEGORIES OF BUGS - IR1-#: - These labels were used for bugs related to the old IR1 interpreter. - The # values reached 6 before the category was closed down. +Refer to User Manual for more details.