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
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*
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))
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
+
+ (+ <single> <integer>) ; uses double-precision
+ (+ <single> (FLOAT <integer> <single>)) ; 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.)