then requesting a BACKTRACE at the debugger prompt gives no information
about where in the user program the problem occurred.
+ (this is apparently mostly fixed on the SPARC and PPC architectures:
+ while giving the backtrace the system complains about "unknown
+ source location: using block start", but apart from that the
+ backtrace seems reasonable. See tests/debug.impure.lisp for a test
+ case)
+
64:
Using the pretty-printer from the command prompt gives funny
results, apparently because the pretty-printer doesn't know
e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
and Pierre Mai.)
-79:
- as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
- The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
- an easily guessable temporary filename in a way which might open
- applications using LOAD-FOREIGN to hijacking by malicious users
- on the same machine. Incantations for doing this safely are
- floating around the net in various "how to write secure programs
- despite Unix" documents, and it would be good to (1) fix this in
- LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
- files and make it share the same new safe logic.
-
- (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
- make the temporary filename less easily guessable)
-
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
This is probably the same bug as 216
-167:
- In sbcl-0.7.3.11, compiling the (illegal) code
- (in-package :cl-user)
- (defmethod prove ((uustk uustk))
- (zap ((frob () nil))
- (frob)))
- gives the (not terribly clear) error message
- ; caught ERROR:
- ; (during macroexpansion of (DEFMETHOD PROVE ...))
- ; can't get template for (FROB NIL NIL)
- The problem seems to be that the code walker used by the DEFMETHOD
- macro is unhappy with the illegal syntax in the method body, and
- is giving an unclear error message.
-
173:
The compiler sometimes tries to constant-fold expressions before
it checks to see whether they can be reached. This can lead to
(list x y)))
(funcall (eval #'foo) 1)))
-269:
- SCALE-FLOAT should accept any integer for its second argument.
-
270:
In the following function constraint propagator optimizes nothing:
collect `(array ,(sb-vm:saetp-specifier x)))))
=> NIL, T (when it should be T, T)
-308: "Characters without names"
- (reported by Bruno Haible sbcl-devel "character names are missing"
- 2004-04-19)
- (graphic-char-p (code-char 255))
- => NIL
- (char-name (code-char 255))
- => NIL
-
- SBCL is unsure of what to do about characters with codes in the
- range 128-255. Currently they are treated as non-graphic, but don't
- have names, which is not compliant with the standard. Various fixes
- are possible, such as
- * giving them names such as NON-ASCII-128;
- * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular);
- * making the characters graphic (makes a certain amount of sense);
- * biting the bullet and implementing Unicode (probably quite hard).
-
309: "Dubious values for implementation limits"
(reported by Bruno Haible sbcl-devel "Incorrect value of
multiple-values-limit" 2004-04-19)
318: "stack overflow in compiler warning with redefined class"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
test suite.
- (setq *print-pretty* nil)
(defstruct foo a)
(setf (find-class 'foo) nil)
(defstruct foo slot-1)
- gives
- ...#<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTUREControl stack guard page temporarily disabled: proceed with caution
- (it's not really clear what it should give: is (SETF FIND-CLASS)
- meant to be enough to delete structure classes from the system?
- Giving a stack overflow is definitely suboptimal, though.)
+ This used to give a stack overflow from within the printer, which has
+ been fixed as of 0.8.16.11. Current result:
+ ; caught ERROR:
+ ; can't compile TYPEP of anonymous or undefined class:
+ ; #<SB-KERNEL:STRUCTURE-CLASSOID FOO>
+ ...
+ debugger invoked on a TYPE-ERROR in thread 19973:
+ The value NIL is not of type FUNCTION.
+
+ CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS)
+ meant to be enough to delete structure classes from the system?
319: "backquote with comma inside array"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
method is applicable, and yet matches neither of the method group
qualifier patterns.
-340: SETF of VALUES using too many values
- (fixed in sbcl-0.8.12.10)
-
341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
(from Paul Dietz' test suite)
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.
+
+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
+ SB!VM:MEMORY-USAGE operations in ROOM T caused
+ unhandled condition (of type SB-INT:BUG):
+ failed AVER: "(SAP= CURRENT END)"
+ Several clever people have taken a shot at this without fixing
+ it; this time around (before sbcl-0.8.13 release) I (WHN) just
+ commented out the SB!VM:MEMORY-USAGE calls until someone figures
+ out how to make them work reliably with the rest of the GC.
+
+ (Note: there's at least one dubious thing in room.lisp: see the
+ comment in VALID-OBJ)
+
+345: backtrace on x86 undefined function
+ In sbcl-0.8.13 (and probably earlier versions), code of the form
+ (flet ((test () (#:undefined-fun 42)))
+ (funcall #'test))
+ yields the debugger with a poorly-functioning backtrace. Brian
+ Downing fixed most of the problems on non-x86 architectures, but on
+ the x86 the backtrace from this evaluation does not reveal anything
+ about the problem. (See tests in debug.impure.lisp)
+
+346: alpha backtrace
+ In sbcl-0.8.13, all backtraces from errors caused by internal errors
+ on the alpha seem to have a "bogus stack frame".
+
+348:
+ Structure slot setters do not preserve evaluation order:
+
+ (defstruct foo (x))
+
+ (let ((i (eval '-2))
+ (x (make-foo)))
+ (funcall #'(setf foo-x)
+ (incf i)
+ (aref (vector x) (incf i)))
+ (foo-x x))
+ => error
+
+349: PPRINT-INDENT rounding implementation decisions
+ At present, pprint-indent (and indeed the whole pretty printer)
+ more-or-less assumes that it's using a monospace font. That's
+ probably not too silly an assumption, but one piece of information
+ the current implementation loses is from requests to indent by a
+ non-integral amount. As of sbcl-0.8.15.9, the system silently
+ truncates the indentation to an integer at the point of request, but
+ maybe the non-integral value should be propagated through the
+ pprinter and only truncated at output? (So that indenting by 1/2
+ then 3/2 would indent by two spaces, not one?)
+
+350: heap overflow when printing bignums
+ (reported by Bruno Haible 2004-10-08)
+ In sbcl-0.8.15.18,
+ * (DEFPARAMETER *BIG* (ASH 1 1000000))
+ *BIG*
+ * (PRINT *BIG*)
+ Argh! gc_find_freeish_pages failed (restart_page), nbytes=110152.
+ It should be straightforward to push the heap overflow threshold
+ up to much larger bignums; Paul Dietz pointed out it would help to
+ use a bignum-printing algorithm which bisected the printed number,
+ rather than stripping off digits one by one, and CSR suggested using
+ iteration rather than recursion to encourage intermediate results
+ to be GCed.
+
+351: suboptimal error handling/reporting when compiling (PUSH (LET ...))
+ In sbcl-0.8.15.18,
+ * (defvar *b*)
+ *B*
+ * (defun oops ()
+ (push *b*
+ (let ((b *b*))
+ (aref b 1))))
+ causes the compiler to die with a TYPE-ERROR in SB-C::EXTRACT-LET-VARS,
+ The value #:G4 is not of type LIST.
+ Since the (LET ...) expression is being misused in PUSH as a
+ SETFable place, it would be more helpful to fail as in
+ * (defun oops2 () (setf (let ((b *b*)) (aref b 1)) *b*))
+ with compilation errors and warnings like
+ ; in: LAMBDA NIL
+ ; ((B *B*))
+ ; caught ERROR:
+ ; illegal function call
+ and
+ ; caught WARNING:
+ ; The function (SETF LET) is undefined, and its name is reserved
+ ; by ANSI CL so that even if it were defined later, the code
+ ; doing so would not be portable.
projects / sbcl.git / blobdiff