X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=7f62d6ce23ae7df5a428f8a25e3462e8222e3738;hb=ed891a4fd882d1b9fe066ab14bcf2107aea95baa;hp=a375a314b74d3e09faba370010777ea5fabb70fc;hpb=2419deec84b45d81610dc8d3db610c3e2f7b9486;p=sbcl.git diff --git a/BUGS b/BUGS index a375a31..7f62d6c 100644 --- a/BUGS +++ b/BUGS @@ -249,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). + 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 @@ -482,6 +479,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 @@ -554,11 +556,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 @@ -1615,22 +1612,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* @@ -1732,6 +1713,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 @@ -1788,34 +1773,6 @@ WORKAROUND: implementation of read circularity, using a symbol as a marker for the previously-referenced object. -413: type-errors in ROOM - - (defvar *a* (make-array (expt 2 27))) - (room) - - Causes a type-error on 32bit SBCL, as various byte-counts in ROOM - implementation overrun fixnums. - - 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... - - Reported by Faré Rideau on sbcl-devel. - -414: strange DISASSEMBLE warning - - Compiling and disassembling - - (defun disassemble-source-form-bug (x y z) - (declare (optimize debug)) - (list x y z)) - - Gives - - WARNING: bogus form-number in form! The source file has probably - been changed too much to cope with. - 415: Issues creating large arrays on x86-64/Linux and x86/Darwin (make-array (1- array-dimension-limit)) @@ -1838,23 +1795,6 @@ WORKAROUND: 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL) as the second frame. -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. - 418: SUBSEQ on lists doesn't support bignum indexes LIST-SUBSEQ* now has all the works necessary to support bignum indexes, @@ -1862,3 +1802,164 @@ WORKAROUND: performance elsewhere. Other generic sequence functions have this problem as well. + +419: stack-allocated indirect closure variables are not popped + + (locally (declare (optimize sb-c::stack-allocate-dynamic-extent + sb-c::stack-allocate-value-cells)) + (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 42) '(1 2 3 4 5 6))) => failure + + Note: as of SBCL 1.0.26.29 this bug no longer affects user code, as + SB-C::STACK-ALLOCATE-VALUE-CELLS needs to be explicitly turned on for + that 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. + +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 + + (+ ) ; uses double-precision + (+ (FLOAT )) ; 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.) + +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.) + +425: reading from closed streams + + Reported by Damien Cassou on sbcl-devel. REPL transcript follows: + + * (open ".bashrc" :direction :input) + # + * (defparameter *s* *) + *S* + * (read-line *s*) + "# -*- Mode: Sh -*-" + * (read-line *s*) + "# Files you make look like rw-r--r--" + * (open-stream-p *s*) + T + * (close *s*) + T + * (open-stream-p *s*) + NIL + * (read-line *s*) + "umask 022" + + The problem is with the fast path using ansi-stream-cin-buffer not hitting + closed-flame. + +426: inlining failure involving multiple nested calls + + (declaim (inline foo)) + (defun foo (x y) + (cons x y)) + (defun bar (x) + (foo (foo x x) (foo x x))) + ;; shows a full call to FOO + (disassemble 'bar) + ;; simple way to test this programmatically + (let ((code (sb-c::fun-code-header #'bar)) + (foo (sb-impl::fdefinition-object 'foo nil))) + (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code) + do (assert (not (eq foo (sb-kernel:code-header-ref code i)))))) + + This appears to be an ancient bug, inherited from CMUCL: reportedly + 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only + one of the calls, but local call analysis fails to inline the call + for the second time. Nikodemus thinks (but is not 100% sure based on + very brief investigation) that the call that is not inlined is the + second nested one. A trivial fix is to call CHANGE-REF-LEAF in known + call for functions already inline converted there, but he is not sure + if this has adverse effects elsewhere. + +427: ANY-REG not good for primitive type T + + ...which is true, of course, but the following should not complain + about it (on x86 and x86-64): + + (sb-alien:with-alien ((buf (array (sb-alien:signed 8) 16)))) + + reported by Stelian Ionescu on sbcl-devel. +