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

failed AVER: (< I 2)
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/>.

where most of the backtrace seems to have been optimized away by TCO, but probably looks something like
typep -> %typep -> %%typep -> classoid-typep -> %ensure-classoid-valid -> %force-cache-flushes -> %invalidate-wrapper -> (setf (gethash nwrapper *previous-nwrappers*))
with *previous-nwrappers* being the hash table in the error

then while that is running, load a bunch of .fasl files
for example (asdf:load-systems 'iolib 'cl-glut-examples 'hunchentoot 'drakma)
(systems picked mostly at random, just looking for things with lots of files/dependencies)

not sure if any specific features of the .fasl files matter, or if the class hierarchy of the classes. They were shaped that way to be similar to a case that happened in real cffi code while loading iolib.