-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.
-
- 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.
-
- d: (fixed in 0.8.1.5)
-
-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.
-
-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.)
-
-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:
- (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).
-
- Daniel Barlow doesn't know what fixed this, but observes that it
- doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T)
- in a fresh SBCL causes
-
- debugger invoked on a SB-INT:BUG in thread 5911:
- failed AVER: "(SAP= CURRENT END)"
-
- unless a GC has happened beforehand.
-
-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.
-
-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:
- 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.)
-
- 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))))))
-
- 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.
-
-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.
-
-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"
- 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.)
-
- 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).
-
-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
-
-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. (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.
-
- 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)
-
-276:
- b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
- c. (defvar *faa*)
- (defmethod faa ((*faa* double-float))
- (set '*faa* (when (< *faa* 0) (- *faa*)))
- (1+ *faa*))
- (faa 1d0) => type error
-
-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 0.8.3.10: please update this
- bug instead of creating new ones
-
- gethostbyname, gethostbyaddr in sb-bsd-sockets
-
-284: Thread safety: special variables
- There are lots of special variables in SBCL, and I feel sure that at
- least some of them are indicative of potentially thread-unsafe
- parts of the system. See doc/internals/notes/threading-specials
-
-286: "recursive known functions"
- Self-call recognition conflicts with known function
- recognition. Currently cross compiler and target COMPILE do not
- recognize recursion, and in target compiler it can be disabled. We
- can always disable it for known functions with RECURSIVE attribute,
- but there remains a possibility of a function with a
- (tail)-recursive simplification pass and transforms/VOPs for base
- cases.
-
-288: fundamental cross-compilation issues (from old UGLINESS file)
- Using host floating point numbers to represent target floating point
- numbers, or host characters to represent target characters, is
- theoretically shaky. (The characters are OK as long as the characters
- are in the ANSI-guaranteed character set, though, so they aren't a
- real problem as long as the sources don't need anything but that;
- the floats are a real problem.)
-
-289: "type checking and source-transforms"
- a.
- (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
- signals type error.
-
- Our policy is to check argument types at the moment of a call. It
- disagrees with ANSI, which says that type assertions are put
- immediately onto argument expressions, but is easier to implement in
- IR1 and is more compatible to type inference, inline expansion,
- etc. IR1-transforms automatically keep this policy, but source
- transforms for associative functions (such as +), being applied
- during IR1-convertion, do not. It may be tolerable for direct calls
- (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.
-
- b. Another aspect of this problem is efficiency. [x y + z +]
- requires less registers than [x y z + +]. This transformation is
- currently performed with source transforms, but it would be good to
- also perform it in IR1 optimization phase.
-
-290: Alpha floating point and denormalized traps
- In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
- hardware or kernel deficiency: the status of the enable/disable
- denormalized-float traps bit seems to be ambiguous; by the time we
- get to os_restore_fp_control after a trap, denormalized traps seem
- to be enabled. Since we don't want a trap every time someone uses a
- denormalized float, in general, we mask out that bit when we restore
- the control word; however, this clobbers any change the user might
- have made.
-
-297:
- LOOP with non-constant arithmetic step clauses suffers from overzealous
- type constraint: code of the form
- (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
- compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
- (0))). However, an integral value of X should be legal, because
- successive adds of integers to double-floats produces double-floats,
- so none of the type restrictions in the code is violated.
-
-300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
- argument type only after having read a character. This is caused
- with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
- exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
- less error prone to have EXPLICIT-CHECK be a local declaration,
- being put into the definition, instead of an attribute being kept in
- a separate file; maybe also put it into SB-EXT?
-
-301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
- in NOTE-ASSUMED-TYPES
- In sbcl-0.8.7.32, compiling the file
- (defun foo (x y)
- (declare (type integer x))
- (declare (type (vector (or hash-table bit)) y))
- (bletch 2 y))
- (defun bar (x y)
- (declare (type integer x))
- (declare (type (simple-array base (2)) y))
- (bletch 1 y))
- gives the error
- failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
-
-303: "nonlinear LVARs" (aka MISC.293)
- (defun buu (x)
- (multiple-value-call #'list
- (block foo
- (multiple-value-prog1
- (eval '(values :a :b :c))
- (catch 'bar
- (if (> x 0)
- (return-from foo
- (eval `(if (> ,x 1)
- 1
- (throw 'bar (values 3 4)))))))))))
-
- (BUU 1) returns garbage.
-
- The problem is that both EVALs sequentially write to the same LVAR.
-
-306: "Imprecise unions of array types"
-
- a. fixed in SBCL 0.9.15.48
-
- b.(subtypep
- 'array
- `(or
- ,@(loop for x across sb-vm:*specialized-array-element-type-properties*
- collect `(array ,(sb-vm:saetp-specifier x)))))
- => NIL, T (when it should be T, T)
-
-309: "Dubious values for implementation limits"
- (reported by Bruno Haible sbcl-devel "Incorrect value of
- multiple-values-limit" 2004-04-19)
- (values-list (make-list 1000000)), on x86/linux, signals a stack
- exhaustion condition, despite MULTIPLE-VALUES-LIMIT being
- significantly larger than 1000000. There are probably similar
- dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp
- around the same time regarding a call to LIST on sparc with 1000
- arguments) and other implementation limit constants.
-
-314: "LOOP :INITIALLY clauses and scope of initializers"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite, originally by Thomas F. Burdick.
- ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
- ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is
- ;; initialized to the result of evaluating form1. 6.1.7.2 says that
- ;; initially clauses are evaluated in the loop prologue, which precedes all
- ;; loop code except for the initial settings provided by with, for, or as.
- (loop :for x = 0 :then (1+ x)
- :for y = (1+ x) :then (ash y 1)
- :for z :across #(1 3 9 27 81 243)
- :for w = (+ x y z)
- :initially (assert (zerop x)) :initially (assert (= 2 w))
- :until (>= w 100) :collect w)
- Expected: (2 6 15 38)
- Got: ERROR
-
-318: "stack overflow in compiler warning with redefined class"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (defstruct foo a)
- (setf (find-class 'foo) nil)
- (defstruct foo slot-1)
- This used to give a stack overflow from within the printer, which has
- been fixed as of 0.8.16.11. Current result:
- ; caught ERROR:
- ; can't compile TYPEP of anonymous or undefined class:
- ; #<SB-KERNEL:STRUCTURE-CLASSOID FOO>
- ...
- debugger invoked on a TYPE-ERROR in thread 19973:
- The value NIL is not of type FUNCTION.
-
- CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS)
- meant to be enough to delete structure classes from the system?
-
-319: "backquote with comma inside array"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (read-from-string "`#1A(1 2 ,(+ 2 2) 4)")
- gives
- #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
- which probably isn't intentional.
-
-324: "STREAMs and :ELEMENT-TYPE with large bytesize"
- In theory, (open foo :element-type '(unsigned-byte <x>)) should work
- for all positive integral <x>. At present, it only works for <x> up
- to about 1024 (and similarly for signed-byte), so
- (open "/dev/zero" :element-type '(unsigned-byte 1025))
- gives an error in sbcl-0.8.10.
-
-325: "CLOSE :ABORT T on supeseding 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.
-
-332: "fasl stack inconsistency in structure redefinition"
- (reported by Tim Daly Jr sbcl-devel 2004-05-06)
- Even though structure redefinition is undefined by the standard, the
- following behaviour is suboptimal: running
- (defun stimulate-sbcl ()
- (let ((filename (format nil "/tmp/~A.lisp" (gensym))))
- ;;create a file which redefines a structure incompatibly
- (with-open-file (f filename :direction :output :if-exists :supersede)
- (print '(defstruct astruct foo) f)
- (print '(defstruct astruct foo bar) f))
- ;;compile and load the file, then invoke the continue restart on
- ;;the structure redefinition error
- (handler-bind ((error (lambda (c) (continue c))))
- (load (compile-file filename)))))
- (stimulate-sbcl)
- and choosing the CONTINUE restart yields the message
- debugger invoked on a SB-INT:BUG in thread 27726:
- fasl stack not empty when it should be
-
-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.
-
-354: XEPs in backtraces
- Under default compilation policy
- (defun test ()
- (throw :unknown t))
- (test)
- Has the XEP for TEST in the backtrace, not the TEST frame itself.
- (sparc and x86 at least)
-
- Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
- is true (instead there appear two TEST frames at least on ppc). The
- underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
- the tail-call for the XEP, since Python has by that time proved that
- the function can never return; same happens if the function holds an
- unconditional call to ERROR.
-
-356: PCL corruption
- (reported by Bruno Haible)
- After the "layout depth conflict" error, the CLOS is left in a state where
- it's not possible to define new standard-class subclasses any more.
- Test case:
- (defclass prioritized-dispatcher ()
- ((dependents :type list :initform nil)))
- (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class)
- (c2 (eql (find-class 'prioritized-dispatcher))))
- t)
- (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
- ()
- (:metaclass sb-pcl:funcallable-standard-class))
- ;; ERROR, Quit the debugger with ABORT
- (defclass typechecking-reader-class (standard-class)
- ())
- Expected: #<STANDARD-CLASS TYPECHECKING-READER-CLASS>
- Got: ERROR "The assertion SB-PCL::WRAPPERS failed."
-
- [ This test case does not cause the error any more. However,
- similar problems can be observed with
-
- (defclass foo (standard-class) ()
- (:metaclass sb-mop:funcallable-standard-class))
- (sb-mop:finalize-inheritance (find-class 'foo))
- ;; ERROR, ABORT
- (defclass bar (standard-class) ())
- (make-instance 'bar)
- ]
-
-357: defstruct inheritance of initforms
- (reported by Bruno Haible)
- When defstruct and defclass (with :metaclass structure-class) are mixed,
- 1. some slot initforms are ignored by the DEFSTRUCT generated constructor
- function, and
- 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably
- OK for initforms that were given in a DEFSTRUCT form, but for those
- given in a DEFCLASS form, I think it qualifies as a bug.)
- Test case:
- (defstruct structure02a
- slot1
- (slot2 t)
- (slot3 (floor pi)))
- (defclass structure02b (structure02a)
- ((slot4 :initform -44)
- (slot5)
- (slot6 :initform t)
- (slot7 :initform (floor (* pi pi)))
- (slot8 :initform 88))
- (:metaclass structure-class))
- (defstruct (structure02c (:include structure02b (slot8 -88)))
- slot9
- (slot10 t)
- (slot11 (floor (exp 3))))
- ;; 1. Form:
- (let ((a (make-structure02c)))
- (list (structure02c-slot4 a)
- (structure02c-slot5 a)
- (structure02c-slot6 a)
- (structure02c-slot7 a)))
- Expected: (-44 nil t 9)
- Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..
- SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..)
- ;; 2. Form:
- (let ((b (make-instance 'structure02c)))
- (list (structure02c-slot2 b)
- (structure02c-slot3 b)
- (structure02c-slot4 b)
- (structure02c-slot6 b)
- (structure02c-slot7 b)
- (structure02c-slot8 b)
- (structure02c-slot10 b)
- (structure02c-slot11 b)))
- Expected: (t 3 -44 t 9 -88 t 20)
- Got: (0 0 0 0 0 0 0 0)
-
-359: wrong default value for ensure-generic-function's :generic-function-class argument
- (reported by Bruno Haible)
- ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says:
- "The remaining arguments are the complete set of keyword arguments
- received by ENSURE-GENERIC-FUNCTION."
- and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS:
- ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not
- supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION."
- This is not the case in SBCL. Test case:
- (defclass my-generic-function (standard-generic-function)
- ()
- (:metaclass sb-pcl:funcallable-standard-class))
- (setf (fdefinition 'foo1)
- (make-instance 'my-generic-function :name 'foo1))
- (ensure-generic-function 'foo1
- :generic-function-class (find-class 'standard-generic-function))
- (class-of #'foo1)
- ; => #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
- (setf (fdefinition 'foo2)
- (make-instance 'my-generic-function :name 'foo2))
- (ensure-generic-function 'foo2)
- (class-of #'foo2)
- Expected: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
- Got: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION>
-
-362: missing error when a slot-definition is created without a name
- (reported by Bruno Haible)
- The MOP says about slot-definition initialization:
- "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument
- is not a symbol which can be used as a variable name. An ERROR is SIGNALled
- if this argument is not supplied."
- Test case:
- (make-instance (find-class 'sb-pcl:standard-direct-slot-definition))
- Expected: ERROR
- Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION NIL>
-
-363: missing error when a slot-definition is created with a wrong documentation object
- (reported by Bruno Haible)
- The MOP says about slot-definition initialization:
- "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled
- if it is not. This argument default to NIL during initialization."
- Test case:
- (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)
- :name 'foo
- :documentation 'not-a-string)
- Expected: ERROR
- Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
-
-369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION
- In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$
- does not hold for VALUES-TYPE-INTERSECTION, even for types which
- can be intersected exactly, so that ASSERTs fail in this test case:
- (in-package :cl-user)
- (let ((types (mapcar #'sb-c::values-specifier-type
- '((values (vector package) &optional)
- (values (vector package) &rest t)
- (values (vector hash-table) &rest t)
- (values (vector hash-table) &optional)
- (values t &optional)
- (values t &rest t)
- (values nil &optional)
- (values nil &rest t)
- (values sequence &optional)
- (values sequence &rest t)
- (values list &optional)
- (values list &rest t)))))
- (dolist (x types)
- (dolist (y types)
- (let ((i (sb-c::values-type-intersection x y)))
- (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
- (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
-
-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.
-
-380: Accessor redefinition fails because of old accessor name
- When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
- find the generic function named by the old accessor name using
- ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
- the GF. If the old name does not name a function, or if the old name
- does not name a generic function, no attempt to find the GF or remove
- any methods is made.
-
- However, if an unrelated GF with an incompatible lambda list exists,
- the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
- tries to find and remove a method with an incompatible lambda list
- from the unrelated generic function.
-
-381: incautious calls to EQUAL in fasl dumping
- Compiling
- (frob #(#1=(a #1#)))
- (frob #(#1=(b #1#)))
- (frob #(#1=(a #1#)))
- in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression
- is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL)
- to detect sharing, in which case fixing it might require either
- getting less ambitious about detecting shared list structure, or
- implementing the moral equivalent of EQUAL hash tables in a
- cycle-tolerant way.
-
-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").
-
-386: SunOS/x86 stack exhaustion handling broken
- According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
- stack exhaustion checking (implemented with a write-protected guard
- page) does not work on SunOS/x86.
-
-388:
- (found by Dmitry Bogomolov)
-
- (defclass foo () ((x :type (unsigned-byte 8))))
- (defclass bar () ((x :type symbol)))
- (defclass baz (foo bar) ())
-
- causes error
-
- SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
- (UNSIGNED-BYTE 8).
-
- [ Can't trigger this any more, as of 2006-08-07 ]
-
-389:
- (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
- others)
-
- ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
- specifying whether they're SINGLE or DOUBLE. This is true for types
- computed by the type system itself, but the compiler type derivation
- short-circuits this and constructs non-canonical types. A temporary
- fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
- the right fix is to remove the abstraction violation in the
- compiler's type deriver.
-
-393: Wrong error from methodless generic function
- (DEFGENERIC FOO (X))
- (FOO 1 2)
- gives NO-APPLICABLE-METHOD rather than an argument count error.
-
-395: Unicode and streams
- One of the remaining problems in SBCL's Unicode support is the lack
- of generality in certain streams.
- a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT)
- to streams made from strings that aren't character strings with
- fill-pointers:
- (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char)))
- (format v "foo")
- v)
- should return a non-simple base string containing "foo" but
- instead errors.
-
- (reported on sbcl-help by "tichy")
-
-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.
-
-402: "DECLAIM DECLARATION does not inform the PCL code-walker"
- reported by Vincent Arkesteijn:
-
- (declaim (declaration foo))
- (defgeneric bar (x))
- (defmethod bar (x)
- (declare (foo x))
- x)
-
- ==> WARNING: The declaration FOO is not understood by
- SB-PCL::SPLIT-DECLARATIONS.
- Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
- SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
- SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
- (Assuming it is a variable declaration without argument).
-
-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.
-
-405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3
- In sbcl-0.9.16.21 on linux/86, compiling
- (declaim (optimize (debug 3)))
- (defstruct foo bar)
- (let ()
- (flet ((i (x) (frob x (foo-bar foo))))
- (i :five)))
- causes a TYPE-ERROR
- The value NIL is not of type SB-C::PHYSENV.
- in MERGE-LETS.
-
-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.
+Refer to User Manual for more details.
projects / sbcl.git / blobdiff