X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=bc3eebd3aad9e7547ff835950eaa4899c7c52952;hb=5e291412ff095a2016388eee8ac265e12d565119;hp=b7270a2fc66561566834334a07f8c973592f7383;hpb=95dbd03af309f57cc87f73c3c32ffba8b4ad33a0;p=sbcl.git diff --git a/BUGS b/BUGS index b7270a2..bc3eebd 100644 --- a/BUGS +++ b/BUGS @@ -84,28 +84,12 @@ WORKAROUND: d: (fixed in 0.8.1.5) -7: - The "compiling top-level form:" output ought to be condensed. - Perhaps any number of such consecutive lines ought to turn into a - single "compiling top-level forms:" line. - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting Process inferior-lisp exited abnormally with code 1 I haven't noticed a repeatable case of this yet. -32: - The printer doesn't report closures very well. This is true in - CMU CL 18b as well: - (defstruct foo bar) - (print #'foo-bar) - gives - # - It would be nice to make closures have a settable name slot, - and make things like DEFSTRUCT and FLET, which create closures, - set helpful values into this slot. - 33: And as long as we're wishing, it would be awfully nice if INSPECT could also report on closures, telling about the values of the bound variables. @@ -151,10 +135,6 @@ WORKAROUND: so they could be supported after all. Very likely SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. -60: - The debugger LIST-LOCATIONS command doesn't work properly. - (How should it work properly?) - 61: Compiling and loading (DEFUN FAIL (X) (THROW 'FAIL-TAG X)) @@ -907,6 +887,14 @@ WORKAROUND: (fixed in 0.8.2.51, but a test case would be good) +276: + b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ. + c. (defvar *faa*) + (defmethod faa ((*faa* double-float)) + (set '*faa* (when (< *faa* 0) (- *faa*))) + (1+ *faa*)) + (faa 1d0) => type error + 278: a. (defun foo () @@ -1535,6 +1523,10 @@ WORKAROUND: (used on non-x86 platforms) being a more complete solution then what is done on x86. + On x86/linux large portions of tests/debug.impure.lisp have been commented + out as failures. The probable culprit for these problems is in x86-call-context + (things work fine on x86/freebsd). + More generally, the debugger internals suffer from excessive x86/non-x86 conditionalization and OAOOMization: refactoring the common parts would be good. @@ -1547,6 +1539,13 @@ WORKAROUND: Has the XEP for TEST in the backtrace, not the TEST frame itself. (sparc and x86 at least) + Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* + is true (instead there appear two TEST frames at least on ppc). The + underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge + the tail-call for the XEP, since Python has by that time proved that + the function can never return; same happens if the function holds an + unconditional call to ERROR. + 355: change-class of generic-function (reported by Bruno Haible) The MOP doesn't support change-class on a generic-function. However, SBCL @@ -2032,12 +2031,69 @@ WORKAROUND: (most-positive-short-float or short-float-infinity) or signalling an error immediately would seem to make more sense. -371: - SBCL 0.8.19 fails on - - (defvar *r* -7043009959286724629649270926654940933664689003233793014518979272497911394287216967075767325693021717277238746020477538876750544587281879084559996466844417586093291189295867052594478662802691926547232838591510540917276694295393715934079679531035912244103731582711556740654671309980075069010778644542022/670550434139267031632063192770201289106737062379324644110801846820471752716238484923370056920388400273070254958650831435834503195629325418985020030706879602898158806736813101434594805676212779217311897830937606064579213895527844045511878668289820732425014254579493444623868748969110751636786165152601) - - (let ((*print-base* 5) - (*read-base* 5) - (*print-radix* nil)) - (assert (= *r* (read-from-string (prin1-to-string *r*))))) +372: floating-point overflow not signalled on ppc/darwin + The following assertions in float.pure.lisp fail on ppc/darwin + (Mac OS X version 10.3.7): + (assert (raises-error? (scale-float 1.0 most-positive-fixnum) + floating-point-overflow)) + (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum)) + floating-point-overflow))) + as the SCALE-FLOAT just returns + #.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: + GC invariant lost, file "gc-common.c", line 605 + on ppc/darwin. Test disabled for the duration. + +375: MISC.555 + (compile nil '(lambda (p1) + (declare (optimize (speed 1) (safety 2) (debug 2) (space 0)) + (type keyword p1)) + (keywordp p1))) + + fails on hairy type check in IR2. + + 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like + transformation could eliminate it). + + 2. From the only call of KEYWORDP the type of its argument is + derived to be KEYWORD. + + 2. Type check for P1 is generated; it uses KEYWORDP to perform the + check, and so references the local function; from the KEYWORDP + argument type new CAST to KEYWORD is generated. The compiler + loops forever. + +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.