X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=5105302e752a1d6f802d1c36e3ee33f843e89274;hb=095564c28a259002c7e34fd1d861f5bbd0a959b6;hp=c38234307f2f09e366b3b1668571f21bc49d58fc;hpb=a163c70e2bef35bf482a785dbfd9c545b4fcd555;p=sbcl.git diff --git a/BUGS b/BUGS index c382343..5105302 100644 --- a/BUGS +++ b/BUGS @@ -167,6 +167,12 @@ WORKAROUND: 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 @@ -190,20 +196,6 @@ WORKAROUND: 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 @@ -1161,23 +1153,6 @@ WORKAROUND: 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) @@ -1225,15 +1200,20 @@ WORKAROUND: 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 - ...# + ... + 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 @@ -1525,9 +1505,6 @@ WORKAROUND: 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) @@ -1573,3 +1550,91 @@ WORKAROUND: 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.