-REPORTING BUGS
+SBCL uses Launchpad to track bugs. The bug database is available at:
-Bugs can be reported on the help mailing list
- sbcl-help@lists.sourceforge.net
-or on the development mailing list
- sbcl-devel@lists.sourceforge.net
+ https://bugs.launchpad.net/sbcl
-Please include enough information in a bug report that someone reading
-it can reproduce the problem, i.e. don't write
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
-but instead
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
- I compile and load the file
- (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
- (LET ((*PRINT-LENGTH* 4))
- (PRINT X Y)))))
- X Y)
- then at the command line type
- (MAKE-FOO)
- the program loops endlessly instead of printing the object.
+Reporting bugs there requires registering at Launchpad. However, bugs
+can also be reported on the mailing list sbcl-bugs, which is
+moderated but does _not_ require subscribing. Simply send email to
+ sbcl-bugs@lists.sourceforge.net
-NOTES:
+and the bug will be checked and added to Launchpad by SBCL maintainers.
-There is also some information on bugs in the manual page and
-in the TODO file. Eventually more such information may move here.
+Historical note: before Launchpad was adopted this file contained a
+list of currently open bugs. If you run into an SBCL bug number in the
+range 1-431 inclusive, it refers to that list.
-The gaps in the number sequence belong to old bug descriptions which
-have gone away (typically because they were fixed, but sometimes for
-other reasons, e.g. because they were moved elsewhere).
-
-
-2:
- DEFSTRUCT almost certainly should overwrite the old LAYOUT information
- instead of just punting when a contradictory structure definition
- is loaded. As it is, if you redefine DEFSTRUCTs in a way which
- changes their layout, you probably have to rebuild your entire
- program, even if you know or guess enough about the internals of
- SBCL to wager that this (undefined in ANSI) operation would be safe.
-
-3: "type checking of structure slots"
- a:
- ANSI specifies that a type mismatch in a structure slot
- initialization value should not cause a warning.
-WORKAROUND:
- This one might not be fixed for a while because while we're big
- believers in ANSI compatibility and all, (1) there's no obvious
- simple way to do it (short of disabling all warnings for type
- mismatches everywhere), and (2) there's a good portable
- workaround, and (3) by their own reasoning, it looks as though
- ANSI may have gotten it wrong. ANSI justifies this specification
- by saying
- The restriction against issuing a warning for type mismatches
- between a slot-initform and the corresponding slot's :TYPE
- option is necessary because a slot-initform must be specified
- in order to specify slot options; in some cases, no suitable
- default may exist.
- However, in SBCL (as in CMU CL or, for that matter, any compiler
- which really understands Common Lisp types) a suitable default
- does exist, in all cases, because the compiler understands the
- concept of functions which never return (i.e. has return type NIL).
- Thus, as a portable workaround, you can use a call to some
- known-never-to-return function as the default. E.g.
- (DEFSTRUCT FOO
- (BAR (ERROR "missing :BAR argument")
- :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
- or
- (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
- (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
- (ERROR "missing required argument"))
- (DEFSTRUCT FOO
- (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
- (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
- (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
- Such code should compile without complaint and work correctly either
- on SBCL or on any other completely compliant Common Lisp system.
-
- b: &AUX argument in a boa-constructor without a default value means
- "do not initilize this slot" and does not cause type error. But
- an error may be signalled at read time and it would be good if
- SBCL did it.
-
- 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.
-
-11:
- It would be nice if the
- caught ERROR:
- (during macroexpansion)
- said what macroexpansion was at fault, e.g.
- caught ERROR:
- (during macroexpansion of IN-PACKAGE,
- during macroexpansion of DEFFOO)
-
-19:
- (I *think* this is a bug. It certainly seems like strange behavior. But
- the ANSI spec is scary, dark, and deep.. -- WHN)
- (FORMAT NIL "~,1G" 1.4) => "1. "
- (FORMAT NIL "~3,1G" 1.4) => "1. "
-
-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:
- (PRINT #'CLASS-NAME)
- gives
- #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
- 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.
-
-35:
- The compiler assumes that any time a function of declared FTYPE
- doesn't signal an error, its arguments were of the declared type.
- E.g. compiling and loading
- (DECLAIM (OPTIMIZE (SAFETY 3)))
- (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DEFUN GAMMA (X) X)
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
- (DEFUN FOO (X)
- (COND ((> (FACTORIAL X) 1.0E6)
- (FORMAT T "too big~%"))
- ((INTEGERP X)
- (FORMAT T "exactly ~S~%" (FACTORIAL X)))
- (T
- (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
- then executing
- (FOO 1.5)
- will cause the INTEGERP case to be selected, giving bogus output a la
- exactly 2.5
- This violates the "declarations are assertions" principle.
- According to the ANSI spec, in the section "System Class FUNCTION",
- this is a case of "lying to the compiler", but the lying is done
- by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
- not by the unexpectedly general definition of FACTORIAL. In any case,
- "declarations are assertions" means that lying to the compiler should
- cause an error to be signalled, and should not cause a bogus
- result to be returned. Thus, the compiler should not assume
- that arbitrary functions check their argument types. (It might
- make sense to add another flag (CHECKED?) to DEFKNOWN to
- identify functions which *do* check their argument types.)
- (Also, verify that the compiler handles declared function
- return types as assertions.)
-
-42:
- The definitions of SIGCONTEXT-FLOAT-REGISTER and
- %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
- supported on FreeBSD because the floating point state is not saved,
- but at least as of FreeBSD 4.0, the floating point state *is* saved,
- so they could be supported after all. Very likely
- SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
-
-45:
- a slew of floating-point-related errors reported by Peter Van Eynde
- on July 25, 2000:
- c: Many expressions generate floating infinity on x86/Linux:
- (/ 1 0.0)
- (/ 1 0.0d0)
- (EXPT 10.0 1000)
- (EXPT 10.0d0 1000)
- PVE's regression tests want them to raise errors. sbcl-0.7.0.5
- on x86/Linux generates the infinities instead. That might or
- might not be conforming behavior, but it's also inconsistent,
- which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
- should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
- generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
- signals an error.
- d: (in section12.erg) various forms a la
- (FLOAT 1 DOUBLE-FLOAT-EPSILON)
- don't give the right behavior.
-
-46:
- type safety errors reported by Peter Van Eynde July 25, 2000:
- k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
- not a binary input stream, but instead cheerfully reads from
- string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
- [ Bug was reported as "from character streams", but in 0.8.3.10 we
- get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ]
-
-
-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))
- (FAIL 12)
- then requesting a BACKTRACE at the debugger prompt gives no information
- about where in the user program the problem occurred.
-
-64:
- Using the pretty-printer from the command prompt gives funny
- results, apparently because the pretty-printer doesn't know
- about user's command input, including the user's carriage return
- that the user, and therefore the pretty-printer thinks that
- the new output block should start indented 2 or more characters
- rightward of the correct location.
-
-67:
- As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
- and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
- crashes SBCL. In general tracing anything which is used in the
- implementation of TRACE is likely to have the same problem.
-
-78:
- ANSI says in one place that type declarations can be abbreviated even
- when the type name is not a symbol, e.g.
- (DECLAIM ((VECTOR T) *FOOVECTOR*))
- SBCL doesn't support this. But ANSI says in another place that this
- isn't allowed. So it's not clear this is a bug after all. (See the
- 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
- the mean of the distribution can be systematically O(0.1%) wrong.
- Just increasing R-I-E-B is probably not a good solution, since
- it would decrease efficiency more than is probably necessary. Perhaps
- using some sort of accept/reject method would be better.
-
-85:
- Internally the compiler sometimes evaluates
- (sb-kernel:type/= (specifier-type '*) (specifier-type t))
- (I stumbled across this when I added an
- (assert (not (eq type1 *wild-type*)))
- in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
- in a type context should probably be translated to T, and so it's
- probably wrong to ask whether it's equal to the T type and then (using
- the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
- (I haven't tried to investigate this bug enough to guess whether
- there might be any user-level symptoms.)
-
- In fact, the type system is likely to depend on this inequality not
- holding... * is not equivalent to T in many cases, such as
- (VECTOR *) /= (VECTOR T).
-
-95:
- The facility for dumping a running Lisp image to disk gets confused
- when run without the PURIFY option, and creates an unnecessarily large
- core file (apparently representing memory usage up to the previous
- high-water mark). Moreover, when the file is loaded, it confuses the
- GC, so that thereafter memory usage can never be reduced below that
- level.
-
-98:
- In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
- CL), out-of-line structure slot setters are horribly inefficient
- whenever the type of the slot is declared, because out-of-line
- structure slot setters are implemented as closures to save space,
- so the compiler doesn't compile the type test into code, but
- instead just saves the type in a lexical closure and interprets it
- at runtime.
- To exercise the problem, compile and load
- (cl:in-package :cl-user)
- (defstruct foo
- (bar (error "missing") :type bar))
- (defvar *foo*)
- (defun wastrel1 (x)
- (loop (setf (foo-bar *foo*) x)))
- (defstruct bar)
- (defvar *bar* (make-bar))
- (defvar *foo* (make-foo :bar *bar*))
- (defvar *setf-foo-bar* #'(setf foo-bar))
- (defun wastrel2 (x)
- (loop (funcall *setf-foo-bar* x *foo*)))
- then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
- use BACKTRACE, to see it's spending all essentially all its time
- in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
- One possible solution would be simply to give up on
- representing structure slot accessors as functions, and represent
- them as macroexpansions instead. This can be inconvenient for users,
- but it's not clear that it's worse than trying to help by expanding
- into a horribly inefficient implementation.
- As a workaround for the problem, #'(SETF FOO) expressions
- can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
-(defmacro efficient-setf-function (place-function-name)
- (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
- ;; a workaround for the problem, encouraging the
- ;; inline expansion of the structure accessor, so
- ;; that the compiler can optimize its type test
- (let ((new-value (gensym "NEW-VALUE-"))
- (structure-value (gensym "STRUCTURE-VALUE-")))
- `(lambda (,new-value ,structure-value)
- (setf (,place-function-name ,structure-value)
- ,new-value))))
- ;; no problem, can just use the ordinary expansion
- `(function (setf ,place-function-name))))
-
-100:
- There's apparently a bug in CEILING optimization which caused
- Douglas Crosher to patch the CMU CL version. Martin Atzmueller
- applied the patches to SBCL and they didn't seem to cause problems
- (as reported sbcl-devel 2001-05-04). However, since the patches
- modify nontrivial code which was apparently written incorrectly
- the first time around, until regression tests are written I'm not
- comfortable merging the patches in the CVS version of SBCL.
-
-108:
- (TIME (ROOM T)) reports more than 200 Mbytes consed even for
- a clean, just-started SBCL system. And it seems to be right:
- (ROOM T) can bring a small computer to its knees for a *long*
- time trying to GC afterwards. Surely there's some more economical
- way to implement (ROOM T).
-
-117:
- When the compiler inline expands functions, it may be that different
- kinds of return values are generated from different code branches.
- E.g. an inline expansion of POSITION generates integer results
- from one branch, and NIL results from another. When that inline
- expansion is used in a context where only one of those results
- is acceptable, e.g.
- (defun foo (x)
- (aref *a1* (position x *a2*)))
- and the compiler can't prove that the unacceptable branch is
- never taken, then bogus type mismatch warnings can be generated.
- If you need to suppress the type mismatch warnings, you can
- suppress the inline expansion,
- (defun foo (x)
- #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
- (aref *a1* (position x *a2*)))
- or, sometimes, suppress them by declaring the result to be of an
- appropriate type,
- (defun foo (x)
- (aref *a1* (the integer (position x *a2*))))
-
- This is not a new compiler problem in 0.7.0, but the new compiler
- transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
- more conspicuous. If you don't need performance from these functions,
- and the bogus warnings are a nuisance for you, you can return to
- your pre-0.7.0 state of grace with
- #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
-
- (see also bug 279)
-
-118:
- as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
- (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
- (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
- when of course it should be NIL. (He says it only fails for X86,
- not SPARC; dunno about Alpha.)
-
- Also, "the same problem exists for LONG-FLOAT-EPSILON,
- DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
- for the -negative- the + is replaced by a - in the test)."
-
- Raymond Toy comments that this is tricky on the X86 since its FPU
- uses 80-bit precision internally.
-
-120b:
- Even in sbcl-0.pre7.x, which is supposed to be free of the old
- non-ANSI behavior of treating the function return type inferred
- from the current function definition as a declaration of the
- return type from any function of that name, the return type of NIL
- is attached to FOO in 120a above, and used to optimize code which
- calls FOO.
-
-124:
- As of version 0.pre7.14, SBCL's implementation of MACROLET makes
- the entire lexical environment at the point of MACROLET available
- in the bodies of the macroexpander functions. In particular, it
- allows the function bodies (which run at compile time) to try to
- access lexical variables (which are only defined at runtime).
- It doesn't even issue a warning, which is bad.
-
- The SBCL behavior arguably conforms to the ANSI spec (since the
- spec says that the behavior is undefined, ergo anything conforms).
- However, it would be better to issue a compile-time error.
- Unfortunately I (WHN) don't see any simple way to detect this
- condition in order to issue such an error, so for the meantime
- SBCL just does this weird broken "conforming" thing.
-
- The ANSI standard says, in the definition of the special operator
- MACROLET,
- The macro-expansion functions defined by MACROLET are defined
- in the lexical environment in which the MACROLET form appears.
- Declarations and MACROLET and SYMBOL-MACROLET definitions affect
- the local macro definitions in a MACROLET, but the consequences
- are undefined if the local macro definitions reference any
- local variable or function bindings that are visible in that
- lexical environment.
- Then it seems to contradict itself by giving the example
- (defun foo (x flag)
- (macrolet ((fudge (z)
- ;The parameters x and flag are not accessible
- ; at this point; a reference to flag would be to
- ; the global variable of that name.
- ` (if flag (* ,z ,z) ,z)))
- ;The parameters x and flag are accessible here.
- (+ x
- (fudge x)
- (fudge (+ x 1)))))
- The comment "a reference to flag would be to the global variable
- of the same name" sounds like good behavior for the system to have.
- but actual specification quoted above says that the actual behavior
- is undefined.
-
- (Since 0.7.8.23 macroexpanders are defined in a restricted version
- of the lexical environment, containing no lexical variables and
- functions, which seems to conform to ANSI and CLtL2, but signalling
- a STYLE-WARNING for references to variables similar to locals might
- be a good thing.)
-
-125:
- (as reported by Gabe Garza on cmucl-help 2001-09-21)
- (defvar *tmp* 3)
- (defun test-pred (x y)
- (eq x y))
- (defun test-case ()
- (let* ((x *tmp*)
- (func (lambda () x)))
- (print (eq func func))
- (print (test-pred func func))
- (delete func (list func))))
- Now calling (TEST-CASE) gives output
- NIL
- NIL
- (#<FUNCTION {500A9EF9}>)
- Evidently Python thinks of the lambda as a code transformation so
- much that it forgets that it's also an object.
-
-135:
- Ideally, uninterning a symbol would allow it, and its associated
- FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
- at least as of sbcl-0.7.0, this isn't the case. Information about
- FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
- essentially in ordinary (non-weak) hash tables keyed by symbols.
- Thus, once a system has an entry in this system, it tends to live
- forever, even when it is uninterned and all other references to it
- are lost.
-
-141: "pretty printing and backquote"
- a.
- * '``(FOO ,@',@S)
- ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
-
- b.
- * (write '`(, .ala.) :readably t :pretty t)
- `(,.ALA.)
-
- (note the space between the comma and the point)
-
-143:
- (reported by Jesse Bouwman 2001-10-24 through the unfortunately
- prominent SourceForge web/db bug tracking system, which is
- unfortunately not a reliable way to get a timely response from
- the SBCL maintainers)
- In the course of trying to build a test case for an
- application error, I encountered this behavior:
- If you start up sbcl, and then lay on CTRL-C for a
- minute or two, the lisp process will eventually say:
- %PRIMITIVE HALT called; the party is over.
- and throw you into the monitor. If I start up lisp,
- attach to the process with strace, and then do the same
- (abusive) thing, I get instead:
- access failure in heap page not marked as write-protected
- and the monitor again. I don't know enough to have the
- faintest idea of what is going on here.
- This is with sbcl 6.12, uname -a reports:
- Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown
- I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
- under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
- it took more than two minutes (but less than five) for me.
-
-145:
- a.
- ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
- FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
- COMPLEX implementation didn't deal with this, and hasn't been
- upgraded to do so. (This doesn't seem to be a high priority
- conformance problem, since seems hard to construct useful code
- where it matters.)
-
- b. (fixed in 0.8.3.43)
-
-146:
- Floating point errors are reported poorly. E.g. on x86 OpenBSD
- with sbcl-0.7.1,
- * (expt 2.0 12777)
- debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
- An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
- No traps are enabled? How can this be?
- It should be possible to be much more specific (overflow, division
- by zero, etc.) and of course the "How can this be?" should be fixable.
-
- See also bugs #45.c and #183
-
-162:
- (reported by Robert E. Brown 2002-04-16)
- When a function is called with too few arguments, causing the
- debugger to be entered, the uninitialized slots in the bad call frame
- seem to cause GCish problems, being interpreted as tagged data even
- though they're not. In particular, executing ROOM in the
- debugger at that point causes AVER failures:
- * (machine-type)
- "X86"
- * (lisp-implementation-version)
- "0.7.2.12"
- * (typep 10)
- ...
- 0] (room)
- ...
- failed AVER: "(SAP= CURRENT END)"
- (Christophe Rhodes reports that this doesn't occur on the SPARC, which
- isn't too surprising since there are many differences in stack
- implementation and GC conservatism between the X86 and other ports.)
-
- 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
- bogus warnings about errors in the constant folding, e.g. in code
- like
- (WHEN X
- (WRITE-STRING (> X 0) "+" "0"))
- compiled in a context where the compiler can prove that X is NIL,
- and the compiler complains that (> X 0) causes a type error because
- NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
- caused a full WARNING, which made the bug really annoying because then
- COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
- code. Since then the warning has been downgraded to STYLE-WARNING,
- so it's still a bug but at least it's a little less annoying.
-
-183: "IEEE floating point issues"
- Even where floating point handling is being dealt with relatively
- well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
- accrued-exceptions and current-exceptions part of the fp control
- word don't seem to bear much relation to reality. E.g. on
- SPARC/SunOS:
- * (/ 1.0 0.0)
-
- debugger invoked on condition of type DIVISION-BY-ZERO:
- arithmetic error DIVISION-BY-ZERO signalled
- 0] (sb-vm::get-floating-point-modes)
-
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS NIL
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
- 0] abort
- * (sb-vm::get-floating-point-modes)
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS (:INEXACT)
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
-
-188: "compiler performance fiasco involving type inference and UNION-TYPE"
- (time (compile
- nil
- '(lambda ()
- (declare (optimize (safety 3)))
- (declare (optimize (compilation-speed 2)))
- (declare (optimize (speed 1) (debug 1) (space 1)))
- (let ((start 4))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26))
- (print (incf start 28)))
- (let ((start 6))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26)))
- (let ((start 10))
- (declare (type (integer 0) start))
- (print (incf start 22))
- (print (incf start 26))))))
-
- This example could be solved with clever enough constraint
- propagation or with SSA, but consider
-
- (let ((x 0))
- (loop (incf x 2)))
-
- The careful type of X is {2k} :-(. Is it really important to be
- able to work with unions of many intervals?
-
-190: "PPC/Linux pipe? buffer? bug"
- In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
- on the PPC/Linux platform, waiting for a zombie env process. This
- is a classic symptom of buffer filling and deadlock, but it seems
- only sporadically reproducible.
-
-191: "Miscellaneous PCL deficiencies"
- (reported by Alexey Dejneka sbcl-devel 2002-08-04)
- a. DEFCLASS does not inform the compiler about generated
- functions. Compiling a file with
- (DEFCLASS A-CLASS ()
- ((A-CLASS-X)))
- (DEFUN A-CLASS-X (A)
- (WITH-SLOTS (A-CLASS-X) A
- A-CLASS-X))
- results in a STYLE-WARNING:
- undefined-function
- SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
-
- APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
- Mai points out that the declamation of functions is in fact
- incorrect in some cases (most notably for structure
- classes). This means that at present erroneous attempts to use
- WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
- won't get the corresponding STYLE-WARNING.
- c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
- lists and &KEY arguments) do not signal errors when they should.
-
-201: "Incautious type inference from compound types"
- a. (reported by APD sbcl-devel 2002-09-17)
- (DEFUN FOO (X)
- (LET ((Y (CAR (THE (CONS INTEGER *) X))))
- (SETF (CAR X) NIL)
- (FORMAT NIL "~S IS ~S, Y = ~S"
- (CAR X)
- (TYPECASE (CAR X)
- (INTEGER 'INTEGER)
- (T '(NOT INTEGER)))
- Y)))
-
- (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
-
- b.
- * (defun foo (x)
- (declare (type (array * (4 4)) x))
- (let ((y x))
- (setq x (make-array '(4 4)))
- (adjust-array y '(3 5))
- (= (array-dimension y 0) (eval `(array-dimension ,y 0)))))
- FOO
- * (foo (make-array '(4 4) :adjustable t))
- NIL
-
-205: "environment issues in cross compiler"
- (These bugs have no impact on user code, but should be fixed or
- documented.)
- a. Macroexpanders introduced with MACROLET are defined in the null
- lexical environment.
- b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
- the null lexical environment.
- c. The cross-compiler cannot inline functions defined in a non-null
- lexical environment.
-
-206: ":SB-FLUID feature broken"
- (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
- Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
- the build.
-
-207: "poorly distributed SXHASH results for compound data"
- SBCL's SXHASH could probably try a little harder. ANSI: "the
- intent is that an implementation should make a good-faith
- effort to produce hash-codes that are well distributed
- within the range of non-negative fixnums". But
- (let ((hits (make-hash-table)))
- (dotimes (i 16)
- (dotimes (j 16)
- (let* ((ij (cons i j))
- (newlist (push ij (gethash (sxhash ij) hits))))
- (when (cdr newlist)
- (format t "~&collision: ~S~%" newlist))))))
- reports lots of collisions in sbcl-0.7.8. A stronger MIX function
- would be an obvious way of fix. Maybe it would be acceptably efficient
- to redo MIX using a lookup into a 256-entry s-box containing
- 29-bit pseudorandom numbers?
-
-211: "keywords processing"
- a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
- number of keyword arguments.
- e. Compiling
-
- (flet ((foo (&key y) (list y)))
- (list (foo :y 1 :y 2)))
-
- issues confusing message
-
- ; in: LAMBDA NIL
- ; (FOO :Y 1 :Y 2)
- ;
- ; caught STYLE-WARNING:
- ; The variable #:G15 is defined but never used.
-
-212: "Sequence functions and circular arguments"
- COERCE, MERGE and CONCATENATE go into an infinite loop when given
- circular arguments; it would be good for the user if they could be
- given an error instead (ANSI 17.1.1 allows this behaviour on the part
- of the implementation, as conforming code cannot give non-proper
- sequences to these functions. MAP also has this problem (and
- solution), though arguably the convenience of being able to do
- (MAP 'LIST '+ FOO '#1=(1 . #1#))
- might be classed as more important (though signalling an error when
- all of the arguments are circular is probably desireable).
-
-213: "Sequence functions and type checking"
- a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
- various complicated, though recognizeable, CONS types [e.g.
- (CONS * (CONS * NULL))
- which according to ANSI should be recognized] (and, in SAFETY 3
- code, should return a list of LENGTH 2 or signal an error)
- b. MAP, when given a type argument that is SUBTYPEP LIST, does not
- check that it will return a sequence of the given type. Fixing
- it along the same lines as the others (cf. work done around
- sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
- entirely straightforward.
- c. All of these functions will silently accept a type of the form
- (CONS INTEGER *)
- whether or not the return value is of this type. This is
- probably permitted by ANSI (see "Exceptional Situations" under
- ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
- know about this escape clause, so code of the form
- (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
- can erroneously return T.
-
-214:
- SBCL 0.6.12.43 fails to compile
-
- (locally
- (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
- (flet ((foo (&key (x :vx x-p)) (list x x-p)))
- (foo 1 2)))
-
- or a more simple example:
-
- (locally
- (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
- (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x))))
-
-215: ":TEST-NOT handling by functions"
- a. FIND and POSITION currently signal errors when given non-NIL for
- both their :TEST and (deprecated) :TEST-NOT arguments, but by
- ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
- means that the effect is "unpredictable but harmless". It's not
- clear what that actually means; it may preclude conforming
- implementations from signalling errors.
- b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
- when conflict occurs. As a quality of implementation issue, it
- might be preferable to treat :TEST and :TEST-NOT as being in some
- sense the same &KEY, and effectively take the first test function in
- the argument list.
- c. Again, a quality of implementation issue: it would be good to issue a
- STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
- WARNING for calls with both :TEST and :TEST-NOT; possibly this
- latter should be WARNed about at execute-time too.
-
-216: "debugger confused by frames with invalid number of arguments"
- In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
- leaves the system confused, enough so that (QUIT) no longer works.
- It's as though the process of working with the uninitialized slot in
- the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
- not be the actual problem. (CMU CL 18c doesn't have problems with this.)
-
- This is probably the same bug as 162
-
-217: "Bad type operations with FUNCTION types"
- In sbcl.0.7.7:
-
- * (values-type-union (specifier-type '(function (base-char)))
- (specifier-type '(function (integer))))
-
- #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
-
- It causes insertion of wrong type assertions into generated
- code. E.g.
-
- (defun foo (x s)
- (let ((f (etypecase x
- (character #'write-char)
- (integer #'write-byte))))
- (funcall f x s)
- (etypecase x
- (character (write-char x s))
- (integer (write-byte x s)))))
-
- Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
-
- (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
- produce invalid code, but type checking is not accurate.)
-
-233: bugs in constraint propagation
- b.
- (declaim (optimize (speed 2) (safety 3)))
- (defun foo (x y)
- (if (typep (prog1 x (setq x y)) 'double-float)
- (+ x 1d0)
- (+ x 2)))
- (foo 1d0 5) => segmentation violation
-
-235: "type system and inline expansion"
- a.
- (declaim (ftype (function (cons) number) acc))
- (declaim (inline acc))
- (defun acc (c)
- (the number (car c)))
-
- (defun foo (x y)
- (values (locally (declare (optimize (safety 0)))
- (acc x))
- (locally (declare (optimize (safety 3)))
- (acc y))))
-
- (foo '(nil) '(t)) => NIL, T.
-
-237: "Environment arguments to type functions"
- a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
- UPGRADED-COMPLEX-PART-TYPE now have an optional environment
- argument, but they ignore it completely. This is almost
- certainly not correct.
- b. Also, the compiler's optimizers for TYPEP have not been informed
- about the new argument; consequently, they will not transform
- calls of the form (TYPEP 1 'INTEGER NIL), even though this is
- just as optimizeable as (TYPEP 1 'INTEGER).
-
-238: "REPL compiler overenthusiasm for CLOS code"
- From the REPL,
- * (defclass foo () ())
- * (defmethod bar ((x foo) (foo foo)) (call-next-method))
- causes approximately 100 lines of code deletion notes. Some
- discussion on this issue happened under the title 'Three "interesting"
- bugs in PCL', resulting in a fix for this oververbosity from the
- compiler proper; however, the problem persists in the interactor
- because the notion of original source is not preserved: for the
- compiler, the original source of the above expression is (DEFMETHOD
- BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
- compiler gets its hands on the code needing compilation from the REPL,
- it has been macroexpanded several times.
-
- A symptom of the same underlying problem, reported by Tony Martinez:
- * (handler-case
- (with-input-from-string (*query-io* " no")
- (yes-or-no-p))
- (simple-type-error () 'error))
- ; in: LAMBDA NIL
- ; (SB-KERNEL:FLOAT-WAIT)
- ;
- ; note: deleting unreachable code
- ; compilation unit finished
- ; printed 1 note
-
-241: "DEFCLASS mysteriously remembers uninterned accessor names."
- (from tonyms on #lisp IRC 2003-02-25)
- In sbcl-0.7.12.55, typing
- (defclass foo () ((bar :accessor foo-bar)))
- (profile foo-bar)
- (unintern 'foo-bar)
- (defclass foo () ((bar :accessor foo-bar)))
- gives the error message
- "#:FOO-BAR already names an ordinary function or a macro."
- So it's somehow checking the uninterned old accessor name instead
- of the new requested accessor name, which seems broken to me (WHN).
-
-242: "WRITE-SEQUENCE suboptimality"
- (observed from clx performance)
- In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
- (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
- (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
- rather than writing the sequence in one go, leading to severe
- performance degradation.
-
-243: "STYLE-WARNING overenthusiasm for unused variables"
- (observed from clx compilation)
- In sbcl-0.7.14, in the presence of the macros
- (DEFMACRO FOO (X) `(BAR ,X))
- (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
- somewhat surprising style warnings are emitted for
- (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
- ; in: LAMBDA (Y)
- ; (LAMBDA (Y) (FOO Y))
- ;
- ; caught STYLE-WARNING:
- ; The variable Y is defined but never used.
-
-245: bugs in disassembler
- a. On X86 an immediate operand for IMUL is printed incorrectly.
- b. On X86 operand size prefix is not recognized.
-
-248: "reporting errors in type specifier syntax"
- (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
- specifier".
-
-251:
- (defun foo (&key (a :x))
- (declare (fixnum a))
- a)
-
- does not cause a warning. (BTW: old SBCL issued a warning, but for a
- function, which was never called!)
-
-256:
- Compiler does not emit warnings for
-
- a. (lambda () (svref (make-array 8 :adjustable t) 1))
-
- b. (lambda (x)
- (list (let ((y (the real x)))
- (unless (floatp y) (error ""))
- y)
- (integer-length x)))
-
- c. (lambda (x)
- (declare (optimize (debug 0)))
- (declare (type vector x))
- (list (fill-pointer x)
- (svref x 1)))
-
-257:
- Complex array type does not have corresponding type specifier.
-
- This is a problem because the compiler emits optimization notes when
- you use a non-simple array, and without a type specifier for hairy
- array types, there's no good way to tell it you're doing it
- intentionally so that it should shut up and just compile the code.
-
- Another problem is confusing error message "asserted type ARRAY
- conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
- compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
-
- The last problem is that when type assertions are converted to type
- checks, types are represented with type specifiers, so we could lose
- complex attribute. (Now this is probably not important, because
- currently checks for complex arrays seem to be performed by
- callees.)
-
-259:
- (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
- warning. Analogous cases with the index and length being equal and
- greater than 0 are warned for; the problem here seems to be that the
- type required for an array reference of this type is (INTEGER 0 (0))
- which is canonicalized to NIL.
-
-260:
- a.
- (let* ((s (gensym))
- (t1 (specifier-type s)))
- (eval `(defstruct ,s))
- (type= t1 (specifier-type s)))
- => NIL, NIL
-
- (fixed in 0.8.1.24)
-
- b. The same for CSUBTYPEP.
-
-261:
- * (let () (list (the (values &optional fixnum) (eval '(values)))))
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type FIXNUM.
-
-262: "yet another bug in inline expansion of local functions"
- Compiler fails on
-
- (defun foo (x y)
- (declare (integer x y))
- (+ (block nil
- (flet ((xyz (u)
- (declare (integer u))
- (if (> (1+ (the unsigned-byte u)) 0)
- (+ 1 u)
- (return (+ 38 (cos (/ u 78)))))))
- (declare (inline xyz))
- (return-from foo
- (* (funcall (eval #'xyz) x)
- (if (> x 30)
- (funcall (if (> x 5) #'xyz #'identity)
- (+ x 13))
- 38)))))
- (sin (* x y))))
-
- Urgh... It's time to write IR1-copier.
-
-265:
- SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
- attempting to use it leads to segmentation violations. This is
- probably because of a bogus implementation of
- os_restore_fp_control().
-
-266:
- David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
- behaviour of streams with element-type (SIGNED-BYTE 8). The patch
- looks reasonable, if not obviously correct; however, it caused the
- PPC/Linux port to segfault during warm-init while loading
- src/pcl/std-class.fasl. A workaround patch was made, but it would
- be nice to understand why the first patch caused problems, and to
- fix the cause if possible.
-
-268: "wrong free declaration scope"
- The following code must signal type error:
-
- (locally (declare (optimize (safety 3)))
- (flet ((foo (x &optional (y (car x)))
- (declare (optimize (safety 0)))
- (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:
-
- (defun foo (x)
- (declare (integer x))
- (declare (optimize speed))
- (typecase x
- (fixnum "hala")
- (fixnum "buba")
- (bignum "hip")
- (t "zuz")))
-
-273:
- Compilation of the following two forms causes "X is unbound" error:
-
- (symbol-macrolet ((x pi))
- (macrolet ((foo (y) (+ x y)))
- (declaim (inline bar))
- (defun bar (z)
- (* z (foo 4)))))
- (defun quux (z)
- (bar z))
-
- (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
-
-274:
- CLHS says that type declaration of a symbol macro should not affect
- its expansion, but in SBCL it does. (If you like magic and want to
- fix it, don't forget to change all uses of MACROEXPAND to
- MACROEXPAND*.)
-
-275:
- The following code (taken from CLOCC) takes a lot of time to compile:
-
- (defun foo (n)
- (declare (type (integer 0 #.large-constant) n))
- (expt 1/10 n))
-
- (fixed in 0.8.2.51, but a test case would be good)
-
-276:
- (defmethod fee ((x fixnum))
- (setq x (/ x 2))
- x)
- (fee 1) => type error
-
- (taken from CLOCC)
-
-278:
- a.
- (defun foo ()
- (declare (optimize speed))
- (loop for i of-type (integer 0) from 0 by 2 below 10
- collect i))
-
- uses generic arithmetic.
-
- b. (fixed in 0.8.3.6)
-
-279: type propagation error -- correctly inferred type goes astray?
- In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
- The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
- &OPTIONAL), not a (INTEGER 1 536870911)
- is emitted when compiling this file:
- (declaim (ftype (function ((integer 0 #.most-positive-fixnum))
- (integer #.most-negative-fixnum 0))
- foo))
- (defun foo (x)
- (- x))
- (defun bar (x)
- (let* (;; Uncomment this for a type mismatch warning indicating
- ;; that the type of (FOO X) is correctly understood.
- #+nil (fs-foo (float-sign (foo x)))
- ;; Uncomment this for a type mismatch warning
- ;; indicating that the type of (ABS (FOO X)) is
- ;; correctly understood.
- #+nil (fs-abs-foo (float-sign (abs (foo x))))
- ;; something wrong with this one though
- (abs-foo (abs (foo x))))
- (declare (type (integer 1 100) abs-foo))
- (print abs-foo)))
-
- (see also bug 117)
-
-280: bogus WARNING about duplicate function definition
- In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline,
- e.g. by
- (declaim (inline bs.min))
- (defun bs.min (bases) nil)
- before compiling the file below, the compiler warns
- Duplicate definition for BS.MIN found in one static
- unit (usually a file).
- when compiling
- (declaim (special *minus* *plus* *stagnant*))
- (defun b.*.min (&optional (x () xp) (y () yp) &rest rest)
- (bs.min avec))
- (define-compiler-macro b.*.min (&rest rest)
- `(bs.min ,@rest))
- (defun afish-d-rbd (pd)
- (if *stagnant*
- (b.*.min (foo-d-rbd *stagnant*))
- (multiple-value-bind (reduce-fn initial-value)
- (etypecase pd
- (list (values #'bs.min 0))
- (vector (values #'bs.min *plus*)))
- (let ((cv-ks (cv (kpd.ks pd))))
- (funcall reduce-fn d-rbds)))))
- (defun bfish-d-rbd (pd)
- (if *stagnant*
- (b.*.min (foo-d-rbd *stagnant*))
- (multiple-value-bind (reduce-fn initial-value)
- (etypecase pd
- (list (values #'bs.min *minus*))
- (vector (values #'bs.min 0)))
- (let ((cv-ks (cv (kpd.ks pd))))
- (funcall reduce-fn d-rbds)))))
-
-281: COMPUTE-EFFECTIVE-METHOD error signalling.
- (slightly obscured by a non-0 default value for
- SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
- It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
- when it finds a method with invalid qualifiers. However, it
- shouldn't signal errors when any such methods are not applicable to
- the particular call being evaluated, and certainly it shouldn't when
- simply precomputing effective methods that may never be called.
- (setf sb-pcl::*max-emf-precompute-methods* 0)
- (defgeneric foo (x)
- (:method-combination +)
- (:method ((x symbol)) 1)
- (:method + ((x number)) x))
- (foo 1) -> ERROR, but should simply return 1
-
- The issue seems to be that construction of a discriminating function
- calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
-
-282: "type checking in full calls"
- In current (0.8.3.6) implementation a CAST in a full call argument
- is not checked; but the continuation between the CAST and the
- combination has the "checked" type and CAST performs unsafe
- coercion; this may lead to errors: if FOO is declared to take a
- FIXNUM, this code will produce garbage on a machine with 30-bit
- fixnums:
-
- (foo (aref (the (array (unsigned-byte 32)) x)))
-
-283: Thread safety: libc functions
- There are places that we call unsafe-for-threading libc functions
- that we should find alternatives for, or put locks around. Known or
- strongly suspected problems, as of 0.8.3.10: please update this
- bug instead of creating new ones
-
- localtime() - called for timezone calculations in code/time.lisp
-
-284: Thread safety: special variables
- There are lots of special variables in SBCL, and I feel sure that at
- least some of them are indicative of potentially thread-unsafe
- parts of the system. See doc/internals/notes/threading-specials
-
-286: "recursive known functions"
- Self-call recognition conflicts with known function
- recognition. Currently cross compiler and target COMPILE do not
- recognize recursion, and in target compiler it can be disabled. We
- can always disable it for known functions with RECURSIVE attribute,
- but there remains a possibility of a function with a
- (tail)-recursive simplification pass and transforms/VOPs for base
- cases.
-
-287: PPC/Linux miscompilation or corruption in first GC
- When the runtime is compiled with -O3 on certain PPC/Linux machines, a
- segmentation fault is reported at the point of first triggered GC,
- during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround,
- the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely
- that this merely obscures, not solves, the underlying problem; as and when
- underlying problems are fixed, it would be worth trying again to provoke
- this problem.
+Refer to User Manual for more details.