On Tuesday, August 5, 2014, Renzo Orsini <orsini@unive.it> wrote:
I encountered the following error both on SBCL on Linux and on Mac OS X when porting a system from CCL:

debugger invoked on a SB-INT:BUG:
  This is probably a bug in SBCL itself. (Alternatively, SBCL might have been
  corrupted by bad user code, e.g. by an undefined Lisp operation like
  (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe
  Lisp code; or there might be a bug in the OS or hardware that SBCL is running
  on.) If it seems to be a bug in SBCL itself, the maintainers would like to
  know about it.  Bug reports are welcome on the SBCL mailing lists, which you
  can find at <http://sbcl.sourceforge.net/>.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY                        ] Retry
                                     compiling #<CL-SOURCE-FILE "sql-fundep" "catalog">.
  1: [ACCEPT                       ] Continue, treating
                                     compiling #<CL-SOURCE-FILE "sql-fundep" "catalog">
                                     as having been successful.
  2:                                 Retry ASDF operation.
  3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
  4: [ABORT                        ] Give up on "normalizer"
  5:                                 Exit debugger, returning to top level.


Is there a way of finding the place in which the error occur, a part from excluding parts of the code from the file catalog? Can I help in same way in finding the error for the maintainers?

If you study the compiler output just before the error and/or the backtrace from the error, you should be able to discern which toplevel form provokes this.

If you are really lucky that form alone is enough to provoke the bug, but more likely it depends on some other pieces of code you have.

...so next step is to remove as much as you can while retaining the error. NB: if there is a lot to remove you may find it faster to start by removing everything except that one form, and then start adding its dependencies back in till the error re-appears in similar form.

A truly minimal test case is NOT required, though.

When supplying the test case take care to include enough of your .sbclrc unless you have verified that it has no effect. (It is not unprecedented for eg. a specific global OPTIMIZE declaration to be required to tickle a bug like this.)


  -- nikodemus