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
(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))
(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)
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
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
#(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 <x>)) should work
for all positive integral <x>. At present, it only works for <x> up
#.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,
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 <class>) 'NIL) causes
+ (FIND-CLASS NIL) to return a #<STANDARD-CLASS NIL>.
+
+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.
projects / sbcl.git / blobdiff