X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=d7ecde8dabd4f75f2770419e017052a8b4f4ee45;hb=53f576d7d796e37a9c51c3c3296341458f046c44;hp=e68157d6a4cbb35ac929321282d5edd1c48e558e;hpb=27763fafd1b170518ac2e85b9344fdddddcfd7c5;p=sbcl.git diff --git a/BUGS b/BUGS index e68157d..d7ecde8 100644 --- a/BUGS +++ b/BUGS @@ -84,12 +84,6 @@ WORKAROUND: 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. @@ -174,6 +168,9 @@ WORKAROUND: 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 @@ -252,20 +249,17 @@ WORKAROUND: 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 @@ -422,6 +416,8 @@ WORKAROUND: 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: @@ -485,6 +481,11 @@ WORKAROUND: (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 @@ -557,11 +558,6 @@ WORKAROUND: 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 @@ -633,6 +629,8 @@ WORKAROUND: 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" @@ -732,11 +730,7 @@ WORKAROUND: 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))) @@ -883,11 +877,9 @@ WORKAROUND: 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 - 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 @@ -1058,7 +1050,7 @@ WORKAROUND: (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. @@ -1141,25 +1133,6 @@ WORKAROUND: 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))) @@ -1404,30 +1377,6 @@ WORKAROUND: Expected: ERROR Got: # -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 @@ -1465,31 +1414,6 @@ WORKAROUND: 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 () @@ -1535,6 +1459,8 @@ WORKAROUND: 385: (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0"); (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0"). + (format nil "~E" 0.01) => "10.e-3" (should be "1.e-2"); + (format nil "~G" 0.01) => "10.e-3" (should be "1.e-2"); 386: SunOS/x86 stack exhaustion handling broken According to , the @@ -1636,22 +1562,6 @@ WORKAROUND: 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* @@ -1753,6 +1663,10 @@ WORKAROUND: 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 @@ -1808,3 +1722,105 @@ WORKAROUND: This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the implementation of read circularity, using a symbol as a marker for the previously-referenced object. + +416: backtrace confusion + + (defun foo (x) + (let ((v "foo")) + (flet ((bar (z) + (oops v z) + (oops z v))) + (bar x) + (bar v)))) + (foo 13) + + gives the correct error, but the backtrace shows + 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL) + as the second frame. + +418: SUBSEQ on lists doesn't support bignum indexes + + LIST-SUBSEQ* now has all the works necessary to support bignum indexes, + but it needs to be verified that changing the DEFKNOWN doesn't kill + performance elsewhere. + + Other generic sequence functions have this problem as well. + +419: stack-allocated indirect closure variables are not popped + + (defun bug419 (x) + (multiple-value-call #'list + (eval '(values 1 2 3)) + (let ((x x)) + (declare (sb-int:truly-dynamic-extent x)) + (flet ((mget (y) + (+ x y)) + (mset (z) + (incf x z))) + (declare (dynamic-extent #'mget #'mset)) + ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))) + + (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure + + Note: as of SBCL 1.0.16.29 this bug no longer affects user code, as + SB-INT:TRULY-DYNAMIC-EXTENT needs to be used instead of + DYNAMIC-EXTENT for this to happen. Proper fix for this bug requires + (Nikodemus thinks) storing the relevant LAMBDA-VARs in a + :DYNAMIC-EXTENT cleanup, and teaching stack analysis how to deal + with them. + +421: READ-CHAR-NO-HANG misbehaviour on Windows Console: + + It seems that on Windows READ-CHAR-NO-HANG hangs if the user + has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P + seems to lie if the OS is buffering input for us on Console.) + + reported by Elliot Slaughter on sbcl-devel 2008/1/10. + +422: out-of-extent return not checked in safe code + + (declaim (optimize safety)) + (funcall (catch 't (block nil (throw 't (lambda () (return)))))) + +behaves ...erratically. Reported by Kevin Reid on sbcl-devel +2007-07-06. (We don't _have_ to check things like this, but we +generally try to check returns in safe code, so we should here too.) + +424: toplevel closures and *CHECK-CONSISTENCY* + + The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true. + + (let ((exported-symbols-alist + (loop for symbol being the external-symbols of :cl + collect (cons symbol + (concatenate 'string + "#" + (string-downcase symbol)))))) + (defun hyperdoc-lookup (symbol) + (cdr (assoc symbol exported-symbols-alist)))) + + (Test-case adapted from CL-PPCRE.) + +428: TIMER SCHEDULE-STRESS and PARALLEL-UNSCHEDULE in + timer.impure.lisp fails + + Failure modes vary. Core problem seems to be (?) recursive entry to + RUN-EXPIRED-TIMERS. + +429: compiler hangs + + Compiling a file with this contents makes the compiler loop in + ORDER-UVL-SETS: + + (declaim (inline storage)) + (defun storage (x) + (the (simple-array flt (*)) (unknown x))) + + (defun test1 (lumps &key cg) + (let ((nodes (map 'list (lambda (lump) (storage lump)) + lumps))) + (setf (aref nodes 0) 2) + (assert (every #'~= (apply #'concatenate 'list nodes) '(2 3 6 9))))) + +431: alien strucure redefinition doesn't work as expected + fixed in 1.0.21.29