11.1 Debugging errors in the delivery image

In general, it is worth avoiding debugging an image that has been delivered at a high delivery level if possible. If you discover a bug:

1. First check if the same error occurs in the original (undelivered) development image. If it does, debug the problem in this image.
2. If the error is not reproducible in the development image, check if it is reproducible in an image delivered at a lower delivery level (try 0, then 1 etc). If it is, read the error message and backtrace carefully. In most cases, this is enough to debug the problem.
3. Make sure you can see messages printed by the application (the runtime output), which may contain useful information. In the case of a graphical application on Microsoft Windows or Macintosh these messages may not normally be visible but can be captured by redirecting the runtime output to a file.

To redirect the runtime output, run the application in a command shell. This means a DOS command window (on Microsoft Windows), Terminal.app (Mac OS X) or a shell (Unix/Linux etc). Enter the application executable filename followed by > followed by the output filename, for example,

on Windows:

C:\Program Files\MyApp> myapp.exe > C:\temp\myapp-output

on Macintosh:

mymac:/Applications/MyApp/MyApp.app/Contents/MacOS 2 % ./myapp > /tmp/myapp-output
4. Consider the possibility that you are trying to use functionality that was removed by delivery. You may need to keep the functionality explicitly, by using one of the deliver keywords described in Retaining or removing functionality.
5. If the problem occurs only in the delivered image and not in the original image, and it is still not clear what the problem is, please contact Lisp Support immediately. Send us your deliver script, all the output of the delivery process and the runtime output of the application itself. This situation is regarded by Lisp Support as a bug that should be fixed.

LispWorks Delivery User Guide - 15 Feb 2015