On Tuesday, August 5, 2014, Renzo Orsini <firstname.lastname@example.org> 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:
failed AVER: (NULL (FUNCTIONAL-ENTRY-FUN LEAF))
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.
(SB-INT:BUG "~@<failed AVER: ~2I~_~A~:>" (NULL (SB-C::FUNCTIONAL-ENTRY-FUN SB-C::LEAF)))
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.)