X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=55bb75401e83e04c09f9de8cdd045e92fc3e4b9b;hb=17532463fa19f2fc2aba53b65c32e200a27ccd6a;hp=98e54acba57d71a704ec12852fe2b9379bafc7f5;hpb=e470d15075046b67add2863185514c47b578e22c;p=sbcl.git diff --git a/BUGS b/BUGS index 98e54ac..55bb754 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 @@ -732,11 +729,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 +876,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 - 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 @@ -988,13 +979,8 @@ WORKAROUND: 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 @@ -1409,42 +1395,6 @@ WORKAROUND: Expected: ERROR Got: # -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 # 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. - 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 @@ -1519,18 +1469,6 @@ WORKAROUND: 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 () @@ -1582,16 +1520,6 @@ WORKAROUND: 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) @@ -1753,3 +1681,114 @@ WORKAROUND: 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. + +411: NAN issues on x86-64 + Test :NAN-COMPARISONS in float.pure.lisp fails on x86-64, and has been + disabled on those platforms. Since x86 does not exhibit any problems + the problem is probably with the new FP implementation.