X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=c4c7cf234427d239ae9f167596852344555c6a83;hb=9837343101c3da7b3a8f94609ec116ec5025436a;hp=8088a3b044301ef8ce4ae8b073c1c8aef82a2a25;hpb=36a379d746b9eb74ba8c5afff40dc5dcb9f4557a;p=sbcl.git diff --git a/BUGS b/BUGS index 8088a3b..c4c7cf2 100644 --- a/BUGS +++ b/BUGS @@ -21,6 +21,36 @@ but instead (MAKE-FOO) the program loops endlessly instead of printing the object. +If you run into a signal related bug, you are getting fatal errors +such as 'signal N is [un]blocked' or just hangs, and you want to send +a useful bug report then: + +- compile sbcl with ldb support (feature :sb-ldb, see + base-target-features.lisp-expr) and change '#define QSHOW_SIGNAL 0' + to '#define QSHOW_SIGNAL 1' in src/runtime/runtime.h. + +- isolate a smallish test case, run it + +- if it just hangs kill it with sigabrt: kill -ABRT + +- print the backtrace from ldb by typing 'ba' + +- attach gdb: gdb -p and get backtraces for all threads: + thread apply all ba + +- if multiple threads are in play then still in gdb, try to get Lisp + backtrace for all threads: 'thread apply all + call_backtrace_from_fp($ebp, 100)'. Substitute $ebp with $rbp on + x86-64. + +- send a report with the backtraces and the output (both stdout, + stderr) produced by sbcl + +- don't forget to include OS and SBCL version + +- if available include info on outcome of the same test with other + versions of SBCL, OS, ... + NOTES: @@ -77,19 +107,6 @@ WORKAROUND: Such code should compile without complaint and work correctly either on SBCL or on any other completely compliant Common Lisp system. - b: &AUX argument in a boa-constructor without a default value means - "do not initilize this slot" and does not cause type error. But - an error may be signalled at read time and it would be good if - SBCL did it. - - 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 +191,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 +272,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 @@ -353,28 +370,6 @@ WORKAROUND: forever, even when it is uninterned and all other references to it are lost. -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - 145: a. ANSI allows types `(COMPLEX ,FOO) to use very hairy values for @@ -422,6 +417,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 +482,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 @@ -513,32 +515,14 @@ WORKAROUND: classes). This means that at present erroneous attempts to use WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS won't get the corresponding STYLE-WARNING. - c. (fixed in 0.8.4.23) -201: "Incautious type inference from compound types" - a. (reported by APD sbcl-devel 2002-09-17) - (DEFUN FOO (X) - (LET ((Y (CAR (THE (CONS INTEGER *) X)))) - (SETF (CAR X) NIL) - (FORMAT NIL "~S IS ~S, Y = ~S" - (CAR X) - (TYPECASE (CAR X) - (INTEGER 'INTEGER) - (T '(NOT INTEGER))) - Y))) - - (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" - - b. - * (defun foo (x) - (declare (type (array * (4 4)) x)) - (let ((y x)) - (setq x (make-array '(4 4))) - (adjust-array y '(3 5)) - (= (array-dimension y 0) (eval `(array-dimension ,y 0))))) - FOO - * (foo (make-array '(4 4) :adjustable t)) - NIL + [much later, in 2006-08] in fact it's no longer erroneous to use + WITH-SLOTS on structure-classes. However, including :METACLASS + STRUCTURE-CLASS in the class definition gives a whole bunch of + function redefinition warnings, so we're still not good to close + this bug... + + c. (fixed in 0.8.4.23) 205: "environment issues in cross compiler" (These bugs have no impact on user code, but should be fixed or @@ -550,11 +534,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 @@ -603,21 +582,14 @@ WORKAROUND: can erroneously return T. 215: ":TEST-NOT handling by functions" - a. FIND and POSITION currently signal errors when given non-NIL for - both their :TEST and (deprecated) :TEST-NOT arguments, but by - ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2 - means that the effect is "unpredictable but harmless". It's not - clear what that actually means; it may preclude conforming - implementations from signalling errors. - b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument - when conflict occurs. As a quality of implementation issue, it - might be preferable to treat :TEST and :TEST-NOT as being in some - sense the same &KEY, and effectively take the first test function in - the argument list. - c. Again, a quality of implementation issue: it would be good to issue a - STYLE-WARNING at compile-time for calls with :TEST-NOT, and a - WARNING for calls with both :TEST and :TEST-NOT; possibly this - latter should be WARNed about at execute-time too. + + We should verify that our handling of :TEST-NOT and :TEST is consistent + for all functions that accept them: that is, signal an error if both + are specified. + + Similarly, a compile-time full warning for calls with both would be good. + + We might also consider a compile-time style warning for :TEST-NOT. 216: "debugger confused by frames with invalid number of arguments" In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q @@ -626,47 +598,9 @@ 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.) - This is probably the same bug as 162 - -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) + (Can't reproduce on x86 linux as of 1.0.20.22 - MGL) - Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. - - (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate.) - -235: "type system and inline expansion" - a. - (declaim (ftype (function (cons) number) acc)) - (declaim (inline acc)) - (defun acc (c) - (the number (car c))) - - (defun foo (x y) - (values (locally (declare (optimize (safety 0))) - (acc x)) - (locally (declare (optimize (safety 3))) - (acc y)))) - - (foo '(nil) '(t)) => NIL, T. + This is probably the same bug as 162 237: "Environment arguments to type functions" a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and @@ -678,32 +612,6 @@ WORKAROUND: calls of the form (TYPEP 1 'INTEGER NIL), even though this is just as optimizeable as (TYPEP 1 'INTEGER). -238: "REPL compiler overenthusiasm for CLOS code" - From the REPL, - * (defclass foo () ()) - * (defmethod bar ((x foo) (foo foo)) (call-next-method)) - causes approximately 100 lines of code deletion notes. Some - discussion on this issue happened under the title 'Three "interesting" - bugs in PCL', resulting in a fix for this oververbosity from the - compiler proper; however, the problem persists in the interactor - because the notion of original source is not preserved: for the - compiler, the original source of the above expression is (DEFMETHOD - BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the - compiler gets its hands on the code needing compilation from the REPL, - it has been macroexpanded several times. - - A symptom of the same underlying problem, reported by Tony Martinez: - * (handler-case - (with-input-from-string (*query-io* " no") - (yes-or-no-p)) - (simple-type-error () 'error)) - ; in: LAMBDA NIL - ; (SB-KERNEL:FLOAT-WAIT) - ; - ; note: deleting unreachable code - ; compilation unit finished - ; printed 1 note - 242: "WRITE-SEQUENCE suboptimality" (observed from clx performance) In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type @@ -746,11 +654,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))) @@ -861,14 +765,6 @@ WORKAROUND: (fixed in 0.8.2.51, but a test case would be good) -276: - b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ. - c. (defvar *faa*) - (defmethod faa ((*faa* double-float)) - (set '*faa* (when (< *faa* 0) (- *faa*))) - (1+ *faa*)) - (faa 1d0) => type error - 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) @@ -897,11 +793,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 - localtime() - called for timezone calculations in code/time.lisp - 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 @@ -916,15 +810,6 @@ WORKAROUND: (tail)-recursive simplification pass and transforms/VOPs for base cases. -287: PPC/Linux miscompilation or corruption in first GC - When the runtime is compiled with -O3 on certain PPC/Linux machines, a - segmentation fault is reported at the point of first triggered GC, - during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround, - the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely - that this merely obscures, not solves, the underlying problem; as and when - underlying problems are fixed, it would be worth trying again to provoke - this problem. - 288: fundamental cross-compilation issues (from old UGLINESS file) Using host floating point numbers to represent target floating point numbers, or host characters to represent target characters, is @@ -1011,13 +896,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 @@ -1086,7 +966,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. @@ -1169,25 +1049,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))) @@ -1208,101 +1069,6 @@ WORKAROUND: Fixing this should also fix a subset of #328 -- update the description with a new test-case then. -337: MAKE-METHOD and user-defined method classes - (reported by Bruno Haible sbcl-devel 2004-06-11) - - In the presence of - -(defclass user-method (standard-method) (myslot)) -(defmacro def-user-method (name &rest rest) - (let* ((lambdalist-position (position-if #'listp rest)) - (qualifiers (subseq rest 0 lambdalist-position)) - (lambdalist (elt rest lambdalist-position)) - (body (subseq rest (+ lambdalist-position 1))) - (required-part - (subseq lambdalist 0 (or - (position-if - (lambda (x) (member x lambda-list-keywords)) - lambdalist) - (length lambdalist)))) - (specializers (mapcar #'find-class - (mapcar (lambda (x) (if (consp x) (second x) t)) - required-part))) - (unspecialized-required-part - (mapcar (lambda (x) (if (consp x) (first x) x)) required-part)) - (unspecialized-lambdalist - (append unspecialized-required-part - (subseq lambdalist (length required-part))))) - `(PROGN - (ADD-METHOD #',name - (MAKE-INSTANCE 'USER-METHOD - :QUALIFIERS ',qualifiers - :LAMBDA-LIST ',unspecialized-lambdalist - :SPECIALIZERS ',specializers - :FUNCTION - (LAMBDA (ARGUMENTS NEXT-METHODS-LIST) - (FLET ((NEXT-METHOD-P () NEXT-METHODS-LIST) - (CALL-NEXT-METHOD (&REST NEW-ARGUMENTS) - (UNLESS NEW-ARGUMENTS (SETQ NEW-ARGUMENTS ARGUMENTS)) - (IF (NULL NEXT-METHODS-LIST) - (ERROR "no next method for arguments ~:S" ARGUMENTS) - (FUNCALL (SB-PCL:METHOD-FUNCTION - (FIRST NEXT-METHODS-LIST)) - NEW-ARGUMENTS (REST NEXT-METHODS-LIST))))) - (APPLY #'(LAMBDA ,unspecialized-lambdalist ,@body) ARGUMENTS))))) - ',name))) - - (progn - (defgeneric test-um03 (x)) - (defmethod test-um03 ((x integer)) - (list* 'integer x (not (null (next-method-p))) (call-next-method))) - (def-user-method test-um03 ((x rational)) - (list* 'rational x (not (null (next-method-p))) (call-next-method))) - (defmethod test-um03 ((x real)) - (list 'real x (not (null (next-method-p))))) - (test-um03 17)) - works, but - - a.(progn - (defgeneric test-um10 (x)) - (defmethod test-um10 ((x integer)) - (list* 'integer x (not (null (next-method-p))) (call-next-method))) - (defmethod test-um10 ((x rational)) - (list* 'rational x (not (null (next-method-p))) (call-next-method))) - (defmethod test-um10 ((x real)) - (list 'real x (not (null (next-method-p))))) - (defmethod test-um10 :after ((x real))) - (def-user-method test-um10 :around ((x integer)) - (list* 'around-integer x - (not (null (next-method-p))) (call-next-method))) - (defmethod test-um10 :around ((x rational)) - (list* 'around-rational x - (not (null (next-method-p))) (call-next-method))) - (defmethod test-um10 :around ((x real)) - (list* 'around-real x (not (null (next-method-p))) (call-next-method))) - (test-um10 17)) - fails with a type error, and - - b.(progn - (defgeneric test-um12 (x)) - (defmethod test-um12 ((x integer)) - (list* 'integer x (not (null (next-method-p))) (call-next-method))) - (defmethod test-um12 ((x rational)) - (list* 'rational x (not (null (next-method-p))) (call-next-method))) - (defmethod test-um12 ((x real)) - (list 'real x (not (null (next-method-p))))) - (defmethod test-um12 :after ((x real))) - (defmethod test-um12 :around ((x integer)) - (list* 'around-integer x - (not (null (next-method-p))) (call-next-method))) - (defmethod test-um12 :around ((x rational)) - (list* 'around-rational x - (not (null (next-method-p))) (call-next-method))) - (def-user-method test-um12 :around ((x real)) - (list* 'around-real x (not (null (next-method-p))) (call-next-method))) - (test-um12 17)) - fails with NO-APPLICABLE-METHOD. - 339: "DEFINE-METHOD-COMBINATION bugs" (reported by Bruno Haible via the clisp test suite) @@ -1325,41 +1091,7 @@ WORKAROUND: iii. supplied-p variables for &optional and &key arguments are not bound. - c. qualifier matching incorrect - (progn - (define-method-combination mc27 () - ((normal ()) - (ignored (:ignore :unused))) - `(list 'result - ,@(mapcar #'(lambda (method) `(call-method ,method)) normal))) - (defgeneric test-mc27 (x) - (:method-combination mc27) - (:method :ignore ((x number)) (/ 0))) - (test-mc27 7)) - - should signal an invalid-method-error, as the :IGNORE (NUMBER) - method is applicable, and yet matches neither of the method group - qualifier patterns. - -343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error - Even the simplest possible overriding of - COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation - as "canonical", does not work: - (defclass my-generic-function (standard-generic-function) () - (:metaclass funcallable-standard-class)) - (defmethod compute-discriminating-function ((gf my-generic-function)) - (let ((dfun (call-next-method))) - (lambda (&rest args) - (apply dfun args)))) - (defgeneric foo (x) - (:generic-function-class my-generic-function)) - (defmethod foo (x) (+ x x)) - (foo 5) - signals an error. This error is the same even if the LAMBDA is - replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)). Maybe the - SET-FUNCALLABLE-INSTANCE-FUN scary stuff in - src/code/target-defstruct.lisp is broken? This seems to be broken - in CMUCL 18e, so it's not caused by a recent change. + c. (fixed in sbcl-0.9.15.15) 344: more (?) ROOM T problems (possibly part of bug 108) In sbcl-0.8.12.51, and off and on leading up to it, the @@ -1402,6 +1134,11 @@ WORKAROUND: The class named B is a forward referenced class. The class named B is a direct superclass of the class named C. + [ Is this actually a bug? DEFCLASS only replaces an existing class + when the class name is the proper name of that class, and in the + above code the class found by (FIND-CLASS 'A) does not have a + proper name. CSR, 2006-08-07 ] + 353: debugger suboptimalities on x86 On x86 backtraces for undefined functions start with a bogus stack frame, and backtraces for throws to unknown catch tags with a "no @@ -1417,68 +1154,6 @@ WORKAROUND: conditionalization and OAOOMization: refactoring the common parts would be good. -354: XEPs in backtraces - Under default compilation policy - (defun test () - (throw :unknown t)) - (test) - Has the XEP for TEST in the backtrace, not the TEST frame itself. - (sparc and x86 at least) - - Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* - is true (instead there appear two TEST frames at least on ppc). The - underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge - the tail-call for the XEP, since Python has by that time proved that - the function can never return; same happens if the function holds an - unconditional call to ERROR. - -355: change-class of generic-function - (reported by Bruno Haible) - The MOP doesn't support change-class on a generic-function. However, SBCL - apparently supports it, since it doesn't give an error or warning when doing - so so. Then, however, it produces wrong results for calls to this generic - function. - ;;; The effective-methods cache: - (progn - (defgeneric testgf35 (x)) - (defmethod testgf35 ((x integer)) - (cons 'integer (if (next-method-p) (call-next-method)))) - (defmethod testgf35 ((x real)) - (cons 'real (if (next-method-p) (call-next-method)))) - (defclass customized5-generic-function (standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - (defmethod sb-pcl:compute-effective-method ((gf customized5-generic-function) method-combination methods) - `(REVERSE ,(call-next-method))) - (list - (testgf35 3) - (progn - (change-class #'testgf35 'customized5-generic-function) - (testgf35 3)))) - Expected: ((INTEGER REAL) (REAL INTEGER)) - Got: ((INTEGER REAL) (INTEGER REAL)) - ;;; The discriminating-function cache: - (progn - (defgeneric testgf36 (x)) - (defmethod testgf36 ((x integer)) - (cons 'integer (if (next-method-p) (call-next-method)))) - (defmethod testgf36 ((x real)) - (cons 'real (if (next-method-p) (call-next-method)))) - (defclass customized6-generic-function (standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - (defmethod sb-pcl:compute-discriminating-function ((gf customized6-generic-function)) - (let ((orig-df (call-next-method))) - #'(lambda (&rest arguments) - (reverse (apply orig-df arguments))))) - (list - (testgf36 3) - (progn - (change-class #'testgf36 'customized6-generic-function) - (testgf36 3)))) - Expected: ((INTEGER REAL) (REAL INTEGER)) - Got: ((INTEGER REAL) (INTEGER REAL)) - 356: PCL corruption (reported by Bruno Haible) After the "layout depth conflict" error, the CLOS is left in a state where @@ -1498,71 +1173,16 @@ WORKAROUND: Expected: # Got: ERROR "The assertion SB-PCL::WRAPPERS failed." -357: defstruct inheritance of initforms - (reported by Bruno Haible) - When defstruct and defclass (with :metaclass structure-class) are mixed, - 1. some slot initforms are ignored by the DEFSTRUCT generated constructor - function, and - 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably - OK for initforms that were given in a DEFSTRUCT form, but for those - given in a DEFCLASS form, I think it qualifies as a bug.) - Test case: - (defstruct structure02a - slot1 - (slot2 t) - (slot3 (floor pi))) - (defclass structure02b (structure02a) - ((slot4 :initform -44) - (slot5) - (slot6 :initform t) - (slot7 :initform (floor (* pi pi))) - (slot8 :initform 88)) - (:metaclass structure-class)) - (defstruct (structure02c (:include structure02b (slot8 -88))) - slot9 - (slot10 t) - (slot11 (floor (exp 3)))) - ;; 1. Form: - (let ((a (make-structure02c))) - (list (structure02c-slot4 a) - (structure02c-slot5 a) - (structure02c-slot6 a) - (structure02c-slot7 a))) - Expected: (-44 nil t 9) - Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND.. - SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..) - ;; 2. Form: - (let ((b (make-instance 'structure02c))) - (list (structure02c-slot2 b) - (structure02c-slot3 b) - (structure02c-slot4 b) - (structure02c-slot6 b) - (structure02c-slot7 b) - (structure02c-slot8 b) - (structure02c-slot10 b) - (structure02c-slot11 b))) - Expected: (t 3 -44 t 9 -88 t 20) - Got: (0 0 0 0 0 0 0 0) - -358: :DECLARE argument to ENSURE-GENERIC-FUNCTION - (reported by Bruno Haible) - According to ANSI CL, ensure-generic-function must accept a :DECLARE - keyword argument. In SBCL 0.8.16 it does not. - Test case: - (progn - (ensure-generic-function 'foo113 :declare '((optimize (speed 3)))) - (sb-pcl:generic-function-declarations #'foo113)) - Expected: ((OPTIMIZE (SPEED 3))) - Got: ERROR - Invalid initialization argument: - :DECLARE - in call for class #. - See also: - The ANSI Standard, Section 7.1.2 - - Bruno notes: The MOP specifies that ensure-generic-function accepts :DECLARATIONS. - The easiest way to be compliant to both specs is to accept both (exclusively - or cumulatively). + [ This test case does not cause the error any more. However, + similar problems can be observed with + + (defclass foo (standard-class) () + (:metaclass sb-mop:funcallable-standard-class)) + (sb-mop:finalize-inheritance (find-class 'foo)) + ;; ERROR, ABORT + (defclass bar (standard-class) ()) + (make-instance 'bar) + ] 359: wrong default value for ensure-generic-function's :generic-function-class argument (reported by Bruno Haible) @@ -1589,151 +1209,6 @@ WORKAROUND: Expected: # Got: # -360: CALL-METHOD not recognized in method-combination body - (reported by Bruno Haible) - This method combination, which adds 'redo' and 'return' restarts for each - method invocation to standard method combination, gives an error in SBCL. - (defun prompt-for-new-values () - (format *debug-io* "~&New values: ") - (list (read *debug-io*))) - (defun add-method-restarts (form method) - (let ((block (gensym)) - (tag (gensym))) - `(BLOCK ,block - (TAGBODY - ,tag - (RETURN-FROM ,block - (RESTART-CASE ,form - (METHOD-REDO () - :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Try calling ~S again." ,method)) - (GO ,tag)) - (METHOD-RETURN (L) - :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Specify return values for ~S call." ,method)) - :INTERACTIVE (LAMBDA () (PROMPT-FOR-NEW-VALUES)) - (RETURN-FROM ,block (VALUES-LIST L))))))))) - (defun convert-effective-method (efm) - (if (consp efm) - (if (eq (car efm) 'CALL-METHOD) - (let ((method-list (third efm))) - (if (or (typep (first method-list) 'method) (rest method-list)) - ; Reduce the case of multiple methods to a single one. - ; Make the call to the next-method explicit. - (convert-effective-method - `(CALL-METHOD ,(second efm) - ((MAKE-METHOD - (CALL-METHOD ,(first method-list) ,(rest method-list)))))) - ; Now the case of at most one method. - (if (typep (second efm) 'method) - ; Wrap the method call in a RESTART-CASE. - (add-method-restarts - (cons (convert-effective-method (car efm)) - (convert-effective-method (cdr efm))) - (second efm)) - ; Normal recursive processing. - (cons (convert-effective-method (car efm)) - (convert-effective-method (cdr efm)))))) - (cons (convert-effective-method (car efm)) - (convert-effective-method (cdr efm)))) - efm)) - (define-method-combination standard-with-restarts () - ((around (:around)) - (before (:before)) - (primary () :required t) - (after (:after))) - (flet ((call-methods-sequentially (methods) - (mapcar #'(lambda (method) - `(CALL-METHOD ,method)) - methods))) - (let ((form (if (or before after (rest primary)) - `(MULTIPLE-VALUE-PROG1 - (PROGN - ,@(call-methods-sequentially before) - (CALL-METHOD ,(first primary) ,(rest primary))) - ,@(call-methods-sequentially (reverse after))) - `(CALL-METHOD ,(first primary))))) - (when around - (setq form - `(CALL-METHOD ,(first around) - (,@(rest around) (MAKE-METHOD ,form))))) - (convert-effective-method form)))) - (defgeneric testgf16 (x) (:method-combination standard-with-restarts)) - (defclass testclass16a () ()) - (defclass testclass16b (testclass16a) ()) - (defclass testclass16c (testclass16a) ()) - (defclass testclass16d (testclass16b testclass16c) ()) - (defmethod testgf16 ((x testclass16a)) - (list 'a - (not (null (find-restart 'method-redo))) - (not (null (find-restart 'method-return))))) - (defmethod testgf16 ((x testclass16b)) - (cons 'b (call-next-method))) - (defmethod testgf16 ((x testclass16c)) - (cons 'c (call-next-method))) - (defmethod testgf16 ((x testclass16d)) - (cons 'd (call-next-method))) - (testgf16 (make-instance 'testclass16d)) - - Expected: (D B C A T T) - Got: ERROR CALL-METHOD outside of a effective method form - - This is a bug because ANSI CL HyperSpec/Body/locmac_call-m__make-method - says - "The macro call-method invokes the specified method, supplying it with - arguments and with definitions for call-next-method and for next-method-p. - If the invocation of call-method is lexically inside of a make-method, - the arguments are those that were supplied to that method. Otherwise - the arguments are those that were supplied to the generic function." - and the example uses nothing more than these two cases (as you can see by - doing (trace convert-effective-method)). - -361: initialize-instance of standard-reader-method ignores :function argument - (reported by Bruno Haible) - Pass a custom :function argument to initialize-instance of a - standard-reader-method instance, but it has no effect. - ;; Check that it's possible to define reader methods that do typechecking. - (progn - (defclass typechecking-reader-method (sb-pcl:standard-reader-method) - ()) - (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs - &key slot-definition) - (let ((name (sb-pcl:slot-definition-name slot-definition)) - (type (sb-pcl:slot-definition-type slot-definition))) - (apply #'call-next-method method - :function #'(lambda (args next-methods) - (declare (ignore next-methods)) - (apply #'(lambda (instance) - (let ((value (slot-value instance name))) - (unless (typep value type) - (error "Slot ~S of ~S is not of type ~S: ~S" - name instance type value)) - value)) - args)) - initargs))) - (defclass typechecking-reader-class (standard-class) - ()) - (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class)) - t) - (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args) - (find-class 'typechecking-reader-method)) - (defclass testclass25 () - ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair)) - (:metaclass typechecking-reader-class)) - (macrolet ((succeeds (form) - `(not (nth-value 1 (ignore-errors ,form))))) - (let ((p (list 'abc 'def)) - (x (make-instance 'testclass25))) - (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17))) - (succeeds (setf (testclass25-pair x) p)) - (succeeds (setf (second p) 456)) - (succeeds (testclass25-pair x)) - (succeeds (slot-value x 'pair)))))) - Expected: (t t t nil t) - Got: (t t t t t) - - (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair))) - shows that the method was created with a FAST-FUNCTION slot but with a - FUNCTION slot of NIL. - 362: missing error when a slot-definition is created without a name (reported by Bruno Haible) The MOP says about slot-definition initialization: @@ -1757,157 +1232,6 @@ WORKAROUND: Expected: ERROR Got: # -364: does not support class objects as specializer names - (reported by Bruno Haible) - According to ANSI CL 7.6.2, class objects are valid specializer names, - and "Parameter specializer names are used in macros intended as the - user-level interface (defmethod)". DEFMETHOD's syntax section doesn't - mention this possibility in the BNF for parameter-specializer-name; - however, this appears to be an editorial omission, since the CLHS - mentions issue CLASS-OBJECT-SPECIALIZER:AFFIRM as being approved - by X3J13. SBCL doesn't support it: - (defclass foo () ()) - (defmethod goo ((x #.(find-class 'foo))) x) - Expected: #)> - Got: ERROR "# is not a legal class name." - -365: mixin on generic-function subclass - (reported by Bruno Haible) - a mixin class - (defclass prioritized-dispatcher () - ((dependents :type list :initform nil))) - on a generic-function subclass: - (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - SBCL gives an error on this, telling to define a method on SB-MOP:VALIDATE-SUPERCLASS. If done, - (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) - (c2 (eql (find-class 'prioritized-dispatcher)))) - t) - then, however, - (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - => debugger invoked on a SIMPLE-ERROR in thread 6687: - layout depth conflict: #(# ...) - - Further discussion on this: http://thread.gmane.org/gmane.lisp.steel-bank.general/491 - -366: cannot define two generic functions with user-defined class - (reported by Bruno Haible) - it is possible to define one generic function class and an instance - of it. But attempting to do the same thing again, in the same session, - leads to a "Control stack exhausted" error. Test case: - (defclass my-generic-function-1 (standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - (defgeneric testgf-1 (x) (:generic-function-class my-generic-function-1) - (:method ((x integer)) (cons 'integer nil))) - (defclass my-generic-function-2 (standard-generic-function) - () - (:metaclass sb-pcl:funcallable-standard-class)) - (defgeneric testgf-2 (x) (:generic-function-class my-generic-function-2) - (:method ((x integer)) (cons 'integer nil))) - => SB-KERNEL::CONTROL-STACK-EXHAUSTED - -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. - -368: miscompiled OR (perhaps related to bug 367) - Trying to relax type declarations to find a workaround for bug 367, - it turns out that even when the return type isn't declared (or - declared to be T, anyway) the system remains confused about type - inference in code similar to that for bug 367: - (in-package :cl-user) - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e368) - (defstruct i368) - (defstruct g368 - (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null))) - (defstruct s368 - (g368 (error "missing :G368") :type g368 :read-only t)) - (declaim (ftype (function (fixnum (vector i368) e368) t) r368)) - (declaim (ftype (function (fixnum (vector e368)) t) h368)) - (defparameter *h368-was-called-p* nil) - (defun nsu (vertices e368) - (let ((i368s (g368-i368s (make-g368)))) - (let ((fuis (r368 0 i368s e368))) - (format t "~&FUIS=~S~%" fuis) - (or fuis (h368 0 i368s))))) - (defun r368 (w x y) - (declare (ignore w x y)) - nil) - (defun h368 (w x) - (declare (ignore w x)) - (setf *h368-was-called-p* t) - (make-s368 :g368 (make-g368))) - (trace r368 h368) - (format t "~&calling NSU~%") - (let ((nsu (nsu #() (make-e368)))) - (format t "~&NSU returned ~S~%" nsu) - (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*) - (assert (s368-p nsu)) - (assert *h368-was-called-p*)) - In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows - that no call to H368 is compiled. - -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 @@ -1945,31 +1269,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 () @@ -2015,22 +1314,14 @@ 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 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) @@ -2043,6 +1334,8 @@ WORKAROUND: SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument (UNSIGNED-BYTE 8). + [ Can't trigger this any more, as of 2006-08-07 ] + 389: (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and others) @@ -2060,25 +1353,6 @@ WORKAROUND: (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) @@ -2129,6 +1403,254 @@ WORKAROUND: For some more details see comments for (define-alien-type-method (c-string :deport-gen) ...) in host-c-call.lisp. -400: "aggressive constant folding" - (fixed in sbcl-0.9.10.17) +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. + +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 ...) + + 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 + (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. + +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