X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=inline;f=BUGS;h=a04ad720ba26c36642d1f1a97eb73415242e744b;hb=0ae8180db142282924d16e1b7d1c54c72ed0d23c;hp=e6de843dcf159e1a72f73772516fcde0d2d88810;hpb=62b0a9c5190806368487d46d8773734cb1ee3a25;p=sbcl.git diff --git a/BUGS b/BUGS index e6de843..a04ad72 100644 --- 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.