Re: [Sbcl-bugs] failed AVER: (NULL (FUNCTIONAL-ENTRY-FUN LEAF))

[Nikodemus S. <nik...@ra...>]

On Tuesday, August 5, 2014, Renzo Orsini <or...@un...> 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
>                                      configuration.
>   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.)

Cheers,

  -- nikodemus