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.
e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
and Pierre Mai.)
+ (Actually this has changed changed since, and types as above are
+ now supported. This may be a bug.)
+
83:
RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
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
+ ROOM issues:
- debugger invoked on a SB-INT:BUG in thread 5911:
- failed AVER: "(SAP= CURRENT END)"
+ a) ROOM works by walking over the heap linearly, instead of
+ following the object graph. Hence, it report garbage objects that
+ are unreachable. (Maybe this is a feature and not a bug?)
- unless a GC has happened beforehand.
+ b) ROOM uses MAP-ALLOCATED-OBJECTS to walk the heap, which doesn't
+ check all pointers as well as it should, and can hence become
+ confused, leading to aver failures. As of 1.0.13.21 these (the
+ SAP= aver in particular) should be mostly under control, but push
+ ROOM hard enough and it still might croak.
117:
When the compiler inline expands functions, it may be that different
This is probably the same bug as 162
-217: "Bad type operations with FUNCTION types"
- In sbcl.0.7.7:
-
- * (values-type-union (specifier-type '(function (base-char)))
- (specifier-type '(function (integer))))
-
- #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
-
- 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.)
-
235: "type system and inline expansion"
a.
(declaim (ftype (function (cons) number) acc))
(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
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)))
+ b. (fixed at some point before 1.0.4.10)
c. (lambda (x)
(declare (optimize (debug 0)))
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
+ strongly suspected problems, as of 1.0.3.13: 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
The problem is that both EVALs sequentially write to the same LVAR.
306: "Imprecise unions of array types"
- a.(defun foo (x)
- (declare (optimize speed)
- (type (or (array cons) (array vector)) x))
- (elt (aref x 0) 0))
- (foo #((0))) => TYPE-ERROR
- relatedly,
+ a. fixed in SBCL 0.9.15.48
b.(subtypep
'array
Expected: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
Got: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION>
-361: initialize-instance of standard-reader-method ignores :function argument
- (reported by Bruno Haible)
- Pass a custom :function argument to initialize-instance of a
- standard-reader-method instance, but it has no effect.
- ;; Check that it's possible to define reader methods that do typechecking.
- (progn
- (defclass typechecking-reader-method (sb-pcl:standard-reader-method)
- ())
- (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs
- &key slot-definition)
- (let ((name (sb-pcl:slot-definition-name slot-definition))
- (type (sb-pcl:slot-definition-type slot-definition)))
- (apply #'call-next-method method
- :function #'(lambda (args next-methods)
- (declare (ignore next-methods))
- (apply #'(lambda (instance)
- (let ((value (slot-value instance name)))
- (unless (typep value type)
- (error "Slot ~S of ~S is not of type ~S: ~S"
- name instance type value))
- value))
- args))
- initargs)))
- (defclass typechecking-reader-class (standard-class)
- ())
- (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class))
- t)
- (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args)
- (find-class 'typechecking-reader-method))
- (defclass testclass25 ()
- ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair))
- (:metaclass typechecking-reader-class))
- (macrolet ((succeeds (form)
- `(not (nth-value 1 (ignore-errors ,form)))))
- (let ((p (list 'abc 'def))
- (x (make-instance 'testclass25)))
- (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17)))
- (succeeds (setf (testclass25-pair x) p))
- (succeeds (setf (second p) 456))
- (succeeds (testclass25-pair x))
- (succeeds (slot-value x 'pair))))))
- Expected: (t t t nil t)
- Got: (t t t t t)
-
- (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair)))
- shows that the method was created with a FAST-FUNCTION slot but with a
- FUNCTION slot of NIL.
-
362: missing error when a slot-definition is created without a name
(reported by Bruno Haible)
The MOP says about slot-definition initialization:
Expected: ERROR
Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
-367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime
- This test program
- (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
- (defstruct e367)
- (defstruct i367)
- (defstruct g367
- (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null)))
- (defstruct s367
- (g367 (error "missing :G367") :type g367 :read-only t))
- ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367))
- ;;; gives an internal error at compile time:
- ;;; The value #<SB-KERNEL:NAMED-TYPE NIL> is not of
- ;;; type SB-KERNEL:VALUES-TYPE.
- (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367))
- (declaim (ftype (function ((vector e367)) (values)) h367))
- (defun frob (v w)
- (let ((x (g367-i367s (make-g367))))
- (let* ((y (or (r367 x w)
- (h367 x)))
- (z (s367-g367 y)))
- (format t "~&Y=~S Z=~S~%" y z)
- (g367-i367s z))))
- (defun r367 (x y) (declare (ignore x y)) nil)
- (defun h367 (x) (declare (ignore x)) (values))
- ;;; In sbcl-0.8.18, executing this form causes an low-level error
- ;;; segmentation violation at #X9B0E1F4
- ;;; (instead of the TYPE-ERROR that one might like).
- (frob 0 (make-e367))
- can be made to cause two different problems, as noted in the comments:
- bug 367a: Compile and load the file. No TYPE-ERROR is signalled at
- run time (in the (S367-G367 Y) form of FROB, when Y is NIL
- instead of an instance of S367). Instead (on x86/Linux at least)
- we end up with a segfault.
- bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile
- the file. The compiler fails with TYPE-ERROR at compile time.
-
-368: miscompiled OR (perhaps related to bug 367)
- Trying to relax type declarations to find a workaround for bug 367,
- it turns out that even when the return type isn't declared (or
- declared to be T, anyway) the system remains confused about type
- inference in code similar to that for bug 367:
- (in-package :cl-user)
- (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
- (defstruct e368)
- (defstruct i368)
- (defstruct g368
- (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null)))
- (defstruct s368
- (g368 (error "missing :G368") :type g368 :read-only t))
- (declaim (ftype (function (fixnum (vector i368) e368) t) r368))
- (declaim (ftype (function (fixnum (vector e368)) t) h368))
- (defparameter *h368-was-called-p* nil)
- (defun nsu (vertices e368)
- (let ((i368s (g368-i368s (make-g368))))
- (let ((fuis (r368 0 i368s e368)))
- (format t "~&FUIS=~S~%" fuis)
- (or fuis (h368 0 i368s)))))
- (defun r368 (w x y)
- (declare (ignore w x y))
- nil)
- (defun h368 (w x)
- (declare (ignore w x))
- (setf *h368-was-called-p* t)
- (make-s368 :g368 (make-g368)))
- (trace r368 h368)
- (format t "~&calling NSU~%")
- (let ((nsu (nsu #() (make-e368))))
- (format t "~&NSU returned ~S~%" nsu)
- (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*)
- (assert (s368-p nsu))
- (assert *h368-was-called-p*))
- In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows
- that no call to H368 is compiled.
-
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
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 ()
stack exhaustion checking (implemented with a write-protected guard
page) does not work on SunOS/x86.
-387:
- 12:10 < jsnell> the package-lock test is basically due to a change in the test
- behaviour when you install a handler for error around it. I
- thought I'd disabled the test for now, but apparently that was
- my imagination
- 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
- 12:19 < Xophe> it's the same problem as we had with compiler-error conditions
- 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
- ERROR, where it probably shouldn't be
-
388:
(found by Dmitry Bogomolov)
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*
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.
+
+407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums
+ (reported by Ariel Badichi on sbcl-devel 2007-01-09)
+ 407a: In sbcl-1.0.1 on Linux x86,
+ (defun foo ()
+ (loop for n from (expt 2 1024) do
+ (handler-case
+ (coerce n 'single-float)
+ (simple-type-error ()
+ (format t "Got here.~%")
+ (return-from foo)))))
+ (foo)
+ causes an infinite loop, where handling the error would be expected.
+ 407b: In sbcl-1.0.1 on Linux x86,
+ (defun bar ()
+ (loop for n from (expt 2 1024) do
+ (handler-case
+ (format t "~E~%" (coerce n 'single-float))
+ (simple-type-error ()
+ (format t "Got here.~%")
+ (return-from bar)))))
+ fails to compile, with
+ Too large to be represented as a SINGLE-FLOAT: ...
+ from
+ 0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...)
+ 1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...)
+ 2: (SB-KERNEL:%SINGLE-FLOAT ...)
+ 3: (SB-C::BOUND-FUNC ...)
+ 4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+
+408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
+ As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
+ (aver (equal (multiple-value-list
+ (subtypep '(or (satisfies x) string)
+ '(or (satisfies x) integer)))
+ '(nil nil)))
+ fails. Also, beneath that failure lurks another failure,
+ (aver (equal (multiple-value-list
+ (subtypep 'string
+ '(or (satisfies x) integer)))
+ '(nil nil)))
+ Having looked at this for an hour or so in sbcl-1.0.2, and
+ specifically having looked at the output from
+ laptop$ sbcl
+ * (let ((x 'string)
+ (y '(or (satisfies x) integer)))
+ (trace sb-kernel::union-complex-subtypep-arg2
+ sb-kernel::invoke-complex-subtypep-arg1-method
+ sb-kernel::type-union
+ sb-kernel::type-intersection
+ sb-kernel::type=)
+ (subtypep x y))
+ my (WHN) impression is that the problem is that the semantics of TYPE=
+ are wrong for what the UNION-COMPLEX-SUBTYPEP-ARG2 code is trying
+ to use it for. The comments on the definition of TYPE= probably
+ date back to CMU CL and seem to define it as a confusing thing:
+ its primary value is something like "certainly equal," and its
+ secondary value is something like "certain about that certainty."
+ I'm left uncertain how to fix UNION-COMPLEX-SUBTYPEP-ARG2 without
+ reducing its generality by removing the TYPE= cleverness. Possibly
+ the tempting TYPE/= relative defined next to it might be a
+ suitable replacement for the purpose. Probably, though, it would
+ be best to start by reverse engineering exactly what TYPE= and
+ TYPE/= do, and writing an explanation which is so clear that one
+ can see immediately what it's supposed to mean in odd cases like
+ (TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet.
+
+409: MORE TYPE SYSTEM PROBLEMS
+ Found while investigating an optimization failure for extended
+ sequences. The extended sequence type implementation was altered to
+ work around the problem, but the fundamental problem remains, to wit:
+ (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio))
+ (sb-kernel:specifier-type 'single-float))
+ returns NIL, NIL on sbcl-1.0.3.
+ (probably related to bug #408)
+
+410: read circularities and type declarations
+ Consider the definition
+ (defstruct foo (a 0 :type (not symbol)))
+ followed by
+ (setf *print-circle* t) ; just in case
+ (read-from-string "#1=#s(foo :a #1#)")
+ This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the
+ implementation of read circularity, using a symbol as a marker for
+ the previously-referenced object.
+
+415: Issues creating large arrays on x86-64/Linux and x86/Darwin
+
+ (make-array (1- array-dimension-limit))
+
+ causes a GC invariant violation on x86-64/Linux, and
+ an unhandled SIGILL on x86/Darwin.
+
+416: backtrace confusion
+
+ (defun foo (x)
+ (let ((v "foo"))
+ (flet ((bar (z)
+ (oops v z)
+ (oops z v)))
+ (bar x)
+ (bar v))))
+ (foo 13)
+
+ gives the correct error, but the backtrace shows
+ 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
+ as the second frame.
+
+418: SUBSEQ on lists doesn't support bignum indexes
+
+ LIST-SUBSEQ* now has all the works necessary to support bignum indexes,
+ but it needs to be verified that changing the DEFKNOWN doesn't kill
+ performance elsewhere.
+
+ Other generic sequence functions have this problem as well.
+
+419: stack-allocated indirect closure variables are not popped
+
+ (locally (declare (optimize speed (safety 0)))
+ (defun bug419 (x)
+ (multiple-value-call #'list
+ (eval '(values 1 2 3))
+ (let ((x x))
+ (declare (dynamic-extent x))
+ (flet ((mget (y)
+ (+ x y))
+ (mset (z)
+ (incf x z)))
+ (declare (dynamic-extent #'mget #'mset))
+ ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))))
+
+ (ASSERT (EQUAL (BUG419) '(1 2 3 4 5 6))) => failure
+
+420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
+
+In sbcl-1.0.13 on Linux/x86, executing
+ (FUNCALL
+ (COMPILE NIL
+ '(LAMBDA (P1 P2)
+ (DECLARE
+ (OPTIMIZE (SPEED 1) (SAFETY 0) (DEBUG 0) (SPACE 0))
+ (TYPE (MEMBER 8174.8604) P1) (TYPE (MEMBER -95195347) P2))
+ (FLOOR P1 P2)))
+ 8174.8604 -95195347)
+interactively causes
+ SB-SYS:MEMORY-FAULT-ERROR: Unhandled memory fault at #x8.
+The gcl/ansi-tests/doit.lisp program terminates prematurely shortly after
+MISC.556 by falling into gdb with
+ fatal error encountered in SBCL pid 2827: Unhandled SIGILL
+unless the MISC.556 test is commented out.
+
+Analysis: + and a number of other arithmetic functions exhibit the
+same behaviour. Here's the underlying problem: On x86 we perform
+single-float + integer normally using double-precision, and then
+coerce the result back to single-float. (The FILD instruction always
+gives us a double-float, and unless we do MOVE-FROM-SINGLE it remains
+one. Or so it seems to me, and that would also explain the observed
+behaviour below.)
+
+During IR1 we derive the types for both
+
+ (+ <single> <integer>) ; uses double-precision
+ (+ <single> (FLOAT <integer> <single>)) ; uses single-precision
+
+and get a mismatch for a number of unlucky arguments. This leads to
+derived result type NIL, and ends up flushing the whole whole
+operation -- and finally we generate code without a return sequence,
+and fall through to whatever.
+
+The use of double-precision in the first case appears to be an
+(un)happy accident -- interval arithmetic gives us the
+double-precision result because that's what the backend does.
+
+ (+ 8172.0 (coerce -95195347 'single-float)) ; => -9.518717e7
+ (+ 8172.0 -95195347) ; => -9.5187176e7
+ (coerce (+ 8172.0 (coerce -95195347 'double-float)) 'single-float)
+ ; => -9.5187176e7
+
+Which should be fixed, the IR1, or the backend?
+
+421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
+
+ It seems that on Windows READ-CHAR-NO-HANG hangs if the user
+ has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P
+ seems to lie if the OS is buffering input for us on Console.)
+
+ reported by Elliot Slaughter on sbcl-devel 2008/1/10.
+
+422: out-of-extent return not checked in safe code
+
+ (declaim (optimize safety))
+ (funcall (catch 't (block nil (throw 't (lambda () (return))))))
+
+behaves ...erratically. Reported by Kevin Reid on sbcl-devel
+2007-07-06. (We don't _have_ to check things like this, but we
+generally try to check returns in safe code, so we should here too.)