Getting Support and Reporting Bugs
**********************************

Volunteer Support
=================

Your primary source of SBCL support should probably be the mailing list sbcl-help: in addition to other users SBCL developers monitor this list and are available for advice. As an anti-spam measure subcription is required for posting:

https://lists.sourceforge.net/lists/listinfo/sbcl-help

Remember that the people answering your question are volunteers, so you stand a much better chance of getting a good answer if you ask a good question.

Before sending mail, check the list archives at either

http://sourceforge.net/mailarchive/forum.php?forum_name=sbcl-help

or

http://news.gmane.org/gmane.lisp.steel-bank.general

to see if your question has been answered already. Checking the bug database is also worth it see Reporting Bugs, to see if the issue is already known.

For general advice on asking good questions, see

http://www.catb.org/~esr/faqs/smart-questions.html.

Commercial Support
==================

There is no formal organization developing SBCL, but if you need a paid support arrangement or custom SBCL development, we maintain the list of companies and consultants below. Use it to identify service providers with appropriate skills and interests, and contact them directly.

The SBCL project cannot verify the accuracy of the information or the competence of the people listed, and they have provided their own blurbs below: you must make your own judgement of suitability from the available information - refer to the links they provide, the CREDITS file, mailing list archives, CVS commit messages, and so on. Please feel free to ask for advice on the sbcl-help list.

Steel Bank Studio Ltd
     provides commercial SBCL support and custom development, is run by SBCL developer Nikodemus Siivola, and has another SBCL developer Richard Kreuter as an affiliated consultant.

     Website: http://sb-studio.net/

     Email: info@sb-studio.net

Christophe Rhodes
     is a researcher and long-time SBCL developer, available for custom development, particularly in the area of language extension.

     Email: c.rhodes@gold.ac.uk

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.

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.

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, ...