X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=8fb3dc53ceecf295a973873a8e0782b41f455b78;hb=5d410bdb150733e21db25c5b4e6814f3775c16c0;hp=506e11a5856bc0b2fd8f1b4a93b450093a19e708;hpb=142a8106721952619aa201f0669d3144b7125925;p=sbcl.git

diff --git a/BUGS b/BUGS
index 506e11a..8fb3dc5 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
@@ -481,20 +473,6 @@ WORKAROUND:
 
   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 
@@ -922,9 +900,6 @@ WORKAROUND:
                (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:
 
@@ -1542,9 +1517,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)
 
@@ -1590,3 +1562,37 @@ 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".
+
+347: FUNCALL forms and compiler-macros
+  (reported by Johan Bockgård on #lisp)
+  The example
+    (funcall (compiler-macro-function 'square) '(funcall #'square x) nil) 
+    => (EXPT X 2)
+  from CLHS entry for DEFINE-COMPILER-MACRO fails in 0.8.13.41 with an
+  error. Fixed in CMUCL 19a.