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.
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
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
(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
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
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)))
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
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 ()
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*
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
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.
+
+415: Issues creating large arrays on x86-64/Linux and x86/Darwin
+
+ (make-array (1- array-dimension-limit))
+
+ causes a GC invariant violation on x86-64/Linux, and
+ an unhandled SIGILL on x86/Darwin.
+
+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
+
+ (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.
+
+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)
+ #<SB-SYS:FD-STREAM for "file /home/cassou/.bashrc" {A6ADFC9}>
+ * (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.
+
+428: TIMER SCHEDULE-STRESS in timer.impure.lisp fails
+
+ Failure modes vary. Core problem seems to be (?) recursive entry to
+ RUN-EXPIRED-TIMERS.