Previous: Commercial Support, Up: Getting Support and Reporting Bugs


1.3 Reporting Bugs

SBCL uses Launchpad to track bugs. The bug database is available at

    https://bugs.launchpad.net/sbcl

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 and the bug will be checked and added to Launchpad by SBCL maintainers.

1.3.1 How to Report Bugs Effectively

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.

A more in-depth discussion on reporting bugs effectively can be found at

    http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.

1.3.2 Signal Related Bugs

If you run into a signal related bug, you are getting fatal errors such as signal N is [un]blocked or just hangs, and you want to send a useful bug report then:

  1. Compile sbcl with ldb support (feature :sb-ldb, see base-target-features.lisp-expr) and change #define QSHOW_SIGNAL 0 to #define QSHOW_SIGNAL 1 in src/runtime/runtime.h.
  2. Isolate a smallish test case, run it.
  3. If it just hangs kill it with sigabrt: kill -ABRT <pidof sbcl>.
  4. Print the backtrace from ldb by typing ba.
  5. Attach gdb: gdb -p <pidof sbcl> and get backtraces for all threads: thread apply all ba.
  6. If multiple threads are in play then still in gdb, try to get Lisp backtrace for all threads: thread apply all call_backtrace_from_fp($ebp, 100). Substitute $ebp with $rbp on x86-64. The backtraces will appear in the stdout of the SBCL process.
  7. Send a report with the backtraces and the output (both stdout and stderr) produced by SBCL.
  8. Don't forget to include OS and SBCL version.
  9. If available include, information on outcome of the same test with other versions of SBCL, OS, ...