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).
+ ROOM issues:
- 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
+ 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?)
- debugger invoked on a SB-INT:BUG in thread 5911:
- failed AVER: "(SAP= CURRENT END)"
-
- 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
isn't too surprising since there are many differences in stack
implementation and GC conservatism between the X86 and other ports.)
+ (Can't reproduce on x86 linux as of 1.0.20.23 - MGL)
+
This is probably the same bug as 216
173:
(print (incf start 22))
(print (incf start 26))))))
+ [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
+ eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
+ below, maybe we should be smarter about when to decide a derived
+ type is "good enough". ]
+
This example could be solved with clever enough constraint
propagation or with SSA, but consider
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
the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
not be the actual problem. (CMU CL 18c doesn't have problems with this.)
+ (Can't reproduce on x86 linux as of 1.0.20.22 - MGL)
+
This is probably the same bug as 162
235: "type system and inline expansion"
(open "/dev/zero" :element-type '(unsigned-byte 1025))
gives an error in sbcl-0.8.10.
-325: "CLOSE :ABORT T on supeseding streams"
+325: "CLOSE :ABORT T on superseding streams"
Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
file on disk, even if one existed before opening.
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)))
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
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.
-
382: externalization unexpectedly changes array simplicity
COMPILE-FILE and LOAD
(defun foo ()
385:
(format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
(format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+ (format nil "~E" 0.01) => "10.e-3" (should be "1.e-2");
+ (format nil "~G" 0.01) => "10.e-3" (should be "1.e-2");
386: SunOS/x86 stack exhaustion handling broken
According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
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*
3: (SB-C::BOUND-FUNC ...)
4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+ These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+ type-error at runtime. The question is, should it instead signal a
+ floating-point overflow, or return an infinity?
+
408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
(aver (equal (multiple-value-list
implementation of read circularity, using a symbol as a marker for
the previously-referenced object.
-413: type-errors in ROOM
+416: backtrace confusion
- (defvar *a* (make-array (expt 2 27)))
- (room)
+ (defun foo (x)
+ (let ((v "foo"))
+ (flet ((bar (z)
+ (oops v z)
+ (oops z v)))
+ (bar x)
+ (bar v))))
+ (foo 13)
- Causes a type-error on 32bit SBCL, as various byte-counts in ROOM
- implementation overrun fixnums.
+ gives the correct error, but the backtrace shows
+ 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
+ as the second frame.
- This was fixed in 1.0.4.89, but the patch was reverted as it caused
- ROOM to cons sufficiently to make running it in a loop deadly on
- GENCGC: newly allocated objects survived to generation 1, where next
- call to ROOM would see them, and allocate even more...
+418: SUBSEQ on lists doesn't support bignum indexes
- Reported by Faré Rideau on sbcl-devel.
+ 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.
-414: strange DISASSEMBLE warning
+ Other generic sequence functions have this problem as well.
- Compiling and disassembling
+419: stack-allocated indirect closure variables are not popped
- (defun disassemble-source-form-bug (x y z)
- (declare (optimize debug))
- (list x y z))
+ (defun bug419 (x)
+ (multiple-value-call #'list
+ (eval '(values 1 2 3))
+ (let ((x x))
+ (declare (sb-int:truly-dynamic-extent x))
+ (flet ((mget (y)
+ (+ x y))
+ (mset (z)
+ (incf x z)))
+ (declare (dynamic-extent #'mget #'mset))
+ ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset)))))
- Gives
+ (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure
- WARNING: bogus form-number in form! The source file has probably
- been changed too much to cope with.
+ Note: as of SBCL 1.0.16.29 this bug no longer affects user code, as
+ SB-INT:TRULY-DYNAMIC-EXTENT needs to be used instead of
+ DYNAMIC-EXTENT for this to happen. Proper fix for this bug requires
+ (Nikodemus thinks) storing the relevant LAMBDA-VARs in a
+ :DYNAMIC-EXTENT cleanup, and teaching stack analysis how to deal
+ with them.
-415: Issues creating large arrays on x86-64/Linux and x86/Darwin
+421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
- (make-array (1- array-dimension-limit))
+ 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.)
- causes a GC invariant violation on x86-64/Linux, and
- an unhandled SIGILL on x86/Darwin.
+ reported by Elliot Slaughter on sbcl-devel 2008/1/10.
-416: backtrace confusion
+422: out-of-extent return not checked in safe code
- (defun foo (x)
- (let ((v "foo"))
- (flet ((bar (z)
- (oops v z)
- (oops z v)))
- (bar x)
- (bar v))))
- (foo 13)
+ (declaim (optimize safety))
+ (funcall (catch 't (block nil (throw 't (lambda () (return))))))
- gives the correct error, but the backtrace shows
- 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
- as the second frame.
+behaves ...erratically. Reported by Kevin Reid on sbcl-devel
+2007-07-06. (We don't _have_ to check things like this, but we
+generally try to check returns in safe code, so we should here too.)
+
+424: toplevel closures and *CHECK-CONSISTENCY*
+
+ The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true.
+
+ (let ((exported-symbols-alist
+ (loop for symbol being the external-symbols of :cl
+ collect (cons symbol
+ (concatenate 'string
+ "#"
+ (string-downcase symbol))))))
+ (defun hyperdoc-lookup (symbol)
+ (cdr (assoc symbol exported-symbols-alist))))
+
+ (Test-case adapted from CL-PPCRE.)
+
+428: TIMER SCHEDULE-STRESS and PARALLEL-UNSCHEDULE in
+ timer.impure.lisp fails
+
+ Failure modes vary. Core problem seems to be (?) recursive entry to
+ RUN-EXPIRED-TIMERS.
+
+429: compiler hangs
+
+ Compiling a file with this contents makes the compiler loop in
+ ORDER-UVL-SETS:
+
+ (declaim (inline storage))
+ (defun storage (x)
+ (the (simple-array flt (*)) (unknown x)))
+
+ (defun test1 (lumps &key cg)
+ (let ((nodes (map 'list (lambda (lump) (storage lump))
+ lumps)))
+ (setf (aref nodes 0) 2)
+ (assert (every #'~= (apply #'concatenate 'list nodes) '(2 3 6 9)))))
-417: Toplevel NIL expressions mess up unreachable code reporting.
- In sbcl-1.0.10.7, COMPILE-FILE on the file
- nil
- (defmethod frob ((package package) stream)
- (if (string= (package-name package) "FOO")
- (pprint-logical-block (stream nil))
- (print-unreadable-object (package stream))))
- causes complaints like
- ; in: SOME SB-C::STRANGE SB-C::PLACE
- ; (SB-C::UNABLE SB-C::TO SB-C::LOCATE SB-C::SOURCE)
- ;
- ; note: deleting unreachable code
- ;
- ; note: deleting unreachable code
- Deleting the toplevel NIL, or even replacing it with 3,
- causes the system not to complain.
+431: alien strucure redefinition doesn't work as expected
+ fixed in 1.0.21.29
projects / sbcl.git / blobdiff