If you discover a bug, in either the software or the documentation, you can submit a bug report by any of the following routes.
The addresses are listed in Send the bug report. Please note that we much prefer email.
Before reporting a bug, please ensure that you have the latest patches installed and loaded. Visit
for the latest patch release.
If the bug persists, check the Lisp Knowledgebase at
for information about the problem - we may already have fixed it or found workarounds.
If you need informal advice or tips, try joining the LispWorks users' mailing list. Details are at
If the problem is poor performance, you should use
profile to check what actually happens. See the
LispWorks User Guide and Reference Manual
for details of these diagnostic functions and macros.
:bug-form "foo is broken" :filename "bug-report-about-foo.txt"
The bug report template captures details of the Operating System and Lisp you are running, as well as a stack backtrace if your Lisp is in the debugger. There may be delays if you do not provide this essential information.
If the issue you are reporting does not signal an error, or for some other reason you are not able to supply a backtrace, we still want to see the bug report template generated from the relevant LispWorks image.
A bug or missing feature that is stopping progress. Probably needs a private patch, possibly under a support contract, unless a workaround can be found.
Either a fix in the next patch bundle or as a private patch, possibly under a support contract.
A fix would be nice in the next minor release.
An item for our wishlist.
Probably not a bug or feature request.
Include any other information you think might be relevant. This might be your code which triggers the bug. In this case, please send us a self-contained piece of code which demonstrates the problem (this is much more useful than code fragments).
Include the output of the Lisp image. In general it is not useful to edit the output, so please send it as-is. Where output files are very large (> 2MB) and repetitive, the first and last 200 lines might be adequate.
t, and try again.
erroror conditions or related functionality, trace
conditions:coerce-to-condition, and try again.
niland try again. This will cause the console version of debugger to be used instead.
toggle-source-debugging nil) and try again.
<**>, please send all of the output--however much there is of it.
terminal output is that written to
*terminal-io*. Normally this is not visible when running the Mac OS X native GUI or the Windows GUI, though it is displayed in a Terminal.app or MS-DOS window if necessary.
Very occasionally, there are circumstances where it is not possible to generate a bug report form from the running Lisp which has the bug. For example, a delivered image may lack the debugger, or the bug may cause lisp to crash completely. In such circumstances:
init.lispwhich loads your code that leads to the crash.
init.lispas the initialization file and with output redirected to a file. For example, on Mac OS X:
% "/Applications/LispWorks 7.0 (32-bit)/LispWorks (32-bit).app/Contents/MacOS/lispworks-7-0-0-x86-darwin" -init init.lisp > lw.out
C:\> "Program Files\LispWorks\lispworks-7-0-0-x86-win32.exe"-init init.lisp > lw.out
% /usr/bin/lispworks-7-0-0-x86-linux -init init.lisp > lw.out
% /usr/lib/lispworks/lib/7-0-0-0/config/lispworks- 7-0-0 -sparc-solaris -init init.lisp > lw.out
lw.outfile to your report. In general it is not useful to edit the output of your Lisp image, so please send it as-is. Where output files are very large (> 2MB) and repetitive, the first and last 200 lines might be adequate.
If your application writes a log file, add this to your report. If your application does not write a log file, consider adding it, since a log is always useful. The log should record what the program is doing, and include the output of
(room) periodically, say every five minutes.
Some delivered executables lack the debugger. It is still useful for us to see a bug report template from your Lisp image that was used to build the delivered executable. If possible, load your code and call
(require "delivery") then generate the template.
For bugs in delivered LispWorks images, the best approach is to start with a very simple call to
deliver, at level 0 and with the minimum of delivery keywords (
:interface :capi and
:multiprocessing t at most). Then deliver at increasingly severe levels. Add delivery keywords to address specific problems you find (see the
LispWorks Delivery User Guide
.for details. However, please note that you are not expected to need to add more than 6 or so delivery keywords: do contact us if you are adding more than this.)
When we receive a bug report, we will send an automated acknowledgment, and the bug will be entered into the LispWorks bug management system. The automated reply has a subject line containing for example
(Lisp Support Call #12345)
that you include a
in your bug report wherever applicable. See Generate a bug report template for details. You can always get a backtrace from within the debugger by entering
:bb at the debugger prompt
We appreciate feedback from users of LispWorks Personal Edition, and often we are able to provide advice or workarounds if you run into problems. However please bear in mind that this free product is unsupported. For informal advice and tips, try joining the LispWorks users mailing list. Details are at
LispWorks Release Notes and Installation Guide - 2 Mar 2015