0.8.21.32: improvement for the space reservation mechanism on OS X

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index e6de843..a04ad72 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -2042,18 +2042,6 @@ WORKAROUND:
  #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
  disabled on Darwin for now.
 
-373: profiling issues on ppc/darwin
- The following bit from smoke.impure.lisp fails on ppc/darwin:
-    (progn
-      (defun profiled-fun ()
-        (random 1d0))
-      (profile profiled-fun)
-      (loop repeat 100000 do (profiled-fun))
-      (report))
- dropping into the debugger with a TYPE-ERROR:
-    The value -1073741382 is not of type UNSIGNED-BYTE.
- The test has been disabled on Darwin till the bug is fixed.
-
 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:
@@ -2079,7 +2067,21 @@ WORKAROUND:
      argument type new CAST to KEYWORD is generated. The compiler
      loops forever.
 
-376: MISC.563
-  Type deriver for CONJUGATE thinks that it returns an object of the
-  same type as its argument, which is wrong for such types as (EQL
-  #C(1 2)).
+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,
+  so we cannot handle the signal directly (as in interrupt_handle_now())
+  in the case when the signal comes from some external agent (the user
+  using kill(1), or a fault in some foreign code, for instance).  As
+  of sbcl-0.8.20.20, this is fixed by calling
+  arrange_return_to_lisp_function() to a new error-signalling
+  function, but as a result the error reporting is poor: we cannot
+  even tell the user at which address the fault occurred.  We should
+  arrange such that arguments can be passed to the function called from
+  arrange_return_to_lisp_function(), but this looked hard to do in
+  general without suffering from memory leaks.
+
+378: floating-point exceptions not signalled on x86-64
+  Floating point traps are currently not enabled on the x86-64 port.
+  This is true for at least overflow detection (as tested in
+  float.pure.lisp) and divide-by-zero.