X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fd35adacef5297b408a28a1a72dee8686f308aea;hb=01e9e8c568777d6480699e6cb3947f38c3bed350;hp=df3898187c3628ea45d3a050be4018c08f5c91bf;hpb=5da5805594423a2d2a841b88617fd2c87fc05750;p=sbcl.git diff --git a/BUGS b/BUGS index df38981..fd35ada 100644 --- a/BUGS +++ b/BUGS @@ -94,6 +94,9 @@ WORKAROUND: 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. @@ -195,19 +198,6 @@ WORKAROUND: holding... * is not equivalent to T in many cases, such as (VECTOR *) /= (VECTOR T). -95: - The facility for dumping a running Lisp image to disk gets confused - when run without the PURIFY option, and creates an unnecessarily large - core file (apparently representing memory usage up to the previous - high-water mark). Moreover, when the file is loaded, it confuses the - GC, so that thereafter memory usage can never be reduced below that - level. - - (As of 0.8.7.3 it's likely that the latter half of this bug is fixed. - The interaction between gencgc and the variables used by - save-lisp-and-die is still nonoptimal, though, so no respite from - big core files yet) - 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 @@ -663,15 +653,6 @@ WORKAROUND: (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not produce invalid code, but type checking is not accurate.) -233: bugs in constraint propagation - b. - (declaim (optimize (speed 2) (safety 3))) - (defun foo (x y) - (if (typep (prog1 x (setq x y)) 'double-float) - (+ x 1d0) - (+ x 2))) - (foo 1d0 5) => segmentation violation - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -888,17 +869,6 @@ WORKAROUND: (1+ *faa*)) (faa 1d0) => type error -278: - a. - (defun foo () - (declare (optimize speed)) - (loop for i of-type (integer 0) from 0 by 2 below 10 - collect i)) - - uses generic arithmetic. - - b. (fixed in 0.8.3.6) - 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) @@ -930,7 +900,7 @@ WORKAROUND: strongly suspected problems, as of 0.8.3.10: please update this bug instead of creating new ones - localtime() - called for timezone calculations in code/time.lisp + 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 @@ -992,14 +962,6 @@ WORKAROUND: the control word; however, this clobbers any change the user might have made. -296: - (reported by Adam Warner, sbcl-devel 2003-09-23) - - The --load toplevel argument does not perform any sanitization of its - argument. As a result, files with Lisp pathname pattern characters - (#\* or #\?, for instance) or quotation marks can cause the system - to perform arbitrary behaviour. - 297: LOOP with non-constant arithmetic step clauses suffers from overzealous type constraint: code of the form @@ -1074,13 +1036,6 @@ WORKAROUND: around the same time regarding a call to LIST on sparc with 1000 arguments) and other implementation limit constants. -311: "Tokeniser not thread-safe" - (see also Robert Marlow sbcl-help "Multi threaded read chucking a - spak" 2004-04-19) - The tokenizer's use of *read-buffer* and *read-buffer-length* causes - spurious errors should two threads attempt to tokenise at the same - time. - 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. @@ -1124,20 +1079,6 @@ WORKAROUND: #(1 2 ((SB-IMPL::|,|) + 2 2) 4) which probably isn't intentional. -323: "REPLACE, BIT-BASH and large strings" - The transform for REPLACE on simple-base-strings uses BIT-BASH, which - at present has an upper limit in size. Consequently, in sbcl-0.8.10 - (defun foo () - (declare (optimize speed (safety 1))) - (let ((x (make-string 140000000)) - (y (make-string 140000000))) - (length (replace x y)))) - (foo) - gives - debugger invoked on a TYPE-ERROR in thread 2412: - The value 1120000000 is not of type (MOD 536870911). - (see also "more and better sequence transforms" sbcl-devel 2004-05-10) - 324: "STREAMs and :ELEMENT-TYPE with large bytesize" In theory, (open foo :element-type '(unsigned-byte )) should work for all positive integral . At present, it only works for up @@ -1400,25 +1341,6 @@ WORKAROUND: method is applicable, and yet matches neither of the method group qualifier patterns. -341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection. - (from Paul Dietz' test suite) - - CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though - that's slightly different) states that these functions perform - circular and shared structure detection on their object. Therefore, - - a.(let ((*print-circle* t)) - (pprint-linear *standard-output* (let ((x '(a))) (list x x)))) - should print "(#1=(A) #1#)" - - b.(let ((*print-circle* t)) - (pprint-linear *standard-output* - (let ((x (cons nil nil))) (setf (cdr x) x) x))) - should print "#1=(NIL . #1#)" - - (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as - suggested by the suggested implementation of PPRINT-TABULAR) - 343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error Even the simplest possible overriding of COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation @@ -2006,31 +1928,6 @@ WORKAROUND: #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been disabled on Darwin for now. -374: BIT-AND problem on ppc/darwin: - The BIT-AND test in bit-vector.impure-cload.lisp results in - fatal error encountered in SBCL pid 8356: - GC invariant lost, file "gc-common.c", line 605 - on ppc/darwin. Test disabled for the duration. - -375: MISC.555 - (compile nil '(lambda (p1) - (declare (optimize (speed 1) (safety 2) (debug 2) (space 0)) - (type keyword p1)) - (keywordp p1))) - - fails on hairy type check in IR2. - - 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like - transformation could eliminate it). - - 2. From the only call of KEYWORDP the type of its argument is - derived to be KEYWORD. - - 2. Type check for P1 is generated; it uses KEYWORDP to perform the - check, and so references the local function; from the KEYWORDP - argument type new CAST to KEYWORD is generated. The compiler - loops forever. - 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, @@ -2045,11 +1942,6 @@ WORKAROUND: arrange_return_to_lisp_function(), but this looked hard to do in general without suffering from memory leaks. -378: floating-point exceptions not signalled on x86-64 - Floating point traps are currently not enabled on the x86-64 port. - This is true for at least overflow detection (as tested in - float.pure.lisp) and divide-by-zero. - 379: TRACE :ENCAPSULATE NIL broken on ppc/darwin See commented-out test-case in debug.impure.lisp. @@ -2077,3 +1969,229 @@ WORKAROUND: 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 , the + 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) + + (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). + +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. + +394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug + (found by PFD ansi-tests) + in sbcl-0.9.7.15, (SETF (CLASS-NAME ) 'NIL) causes + (FIND-CLASS NIL) to return a #. + +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.