Re: [j-devel] problems with SLIME

[Peter G. <pe...@ar...>]

On Sat, 17 Mar 2007 at 13:53:04 +0200, Alex Mizrahi wrote:
> ABCL is able to compile discriminating function (efective method, or what a 
> hell does CLOS try to compile) normally, but when it tries to compile it 
> when called by SLIME debugger it crashes..
> so for next step i'll try to analyze what on this call stack affects 
> compiler a way it produces wrong code..
>
> it's also interesting why first run is different from subsequent ones. most 
> likely that it's because in first run it compiles code, and calls that 
> PRINT-OBJECT, so CLOS compiles it's functions beforehands.

The code being compiled in the case you're talking about is the lambda
form at line 1226 of clos.lisp.

The brokenness is very strange: the call to ERROR is being miscompiled,
with the wrong signature for the invokevirtual call, so that it
consumes only 1 of its 5 arguments, thus leading to the stack imbalance.

Compiling the same lambda form from the repl works fine.

My current working hypothesis is that in the broken case, slime is
somehow using the compiler in a situation where it (or possibly CLOS)
is not properly initialized (although even so, I still can't imagine
anything that would cause the specific breakage I'm seeing).

Your (make-condition 'undefined-function) trick most likely works
because it's forcing the required infrastructure to be autoloaded, in
the same way that things work correctly when slime has to compile all
of its files first on startup. (Yes, autoloading is most likely the
root of all this evil.)

-Peter