X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=4d5e3b43df9bccb0b56c1e7067aa5a40a1cfee2f;hb=78689792e8f8d20b3b931f508f3a9eca81b64f1f;hp=09fe1a74938576ecd3f3bbadf2e36e6a2bfe0cab;hpb=1998ef5334d3209f0fb511788d2c06fe04832d43;p=sbcl.git

diff --git a/BUGS b/BUGS
index 09fe1a7..4d5e3b4 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
@@ -1569,3 +1575,19 @@ WORKAROUND:
   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".