[slime-devel] leopard + sbcl + sb-thread

[Nikodemus Siivola]

On Mon, May 19, 2008 at 4:58 AM, Aaron Feng <aaron.feng at gmail.com> wrote:
> Hi Nikodemus,
>
>> This doesn't make sense to me. As far I've understood, the backtrace
>> occurred in *inferior-lisp*, and there should be no "more" there after
>> typing the "ba" at the debugger prompt.
>
> When I load up emacs this is *exactly* what I see:
>
> The value 68089408 is not of type SIMPLE-STRING.
>    [Condition of type TYPE-ERROR]
>
> Restarts:
>  0: [ABORT] Return to SLIME's top level.
>  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {14132649}>)
>
> Backtrace:
>   0: (SB-KERNEL:%SXHASH-SIMPLE-STRING #<unavailable argument>)
>   1: ((FLET SB-C::LOOKUP) (#<SB-C::VOLATILE-INFO-ENV "Working">
> #<SB-C::COMPACT-INFO-ENV #1="Auxiliary"> #<SB-C::COMPACT-INFO-ENV #1#>))
>   2: (MACRO-FUNCTION #<error printing object>)
>  --more--

I kind of wish you had posted this in the first place. :) Because your
first message didn't have the [Condition of TYPE-ERROR] I assume that
the debugger was the SBCL debugger inside *inferior-lisp*, not the
Slime debugger inside an SLDB buffer -- and they work quite
differently.

At any rate, hitting neither ba not b will get you the backtrace we
desire here. Here just clicking on the --more-- is indeed the right
thing to do -- and if another --more-- appears further down clicking
on it again till you have the full backtrace. ...but you don't need to
do that now, since *slime-events* had everything I wanted to know.
Just for future reference.

In *slime-events* you have:

	("The value 68089408 is not of type SIMPLE-STRING." "   [Condition of
type TYPE-ERROR]" nil)
	(("ABORT" "Return to SLIME's top level.")
	 ("TERMINATE-THREAD" "Terminate this thread (#<THREAD \"worker\"
{1411A649}>)"))
	((0 "(SB-KERNEL:%SXHASH-SIMPLE-STRING #<unavailable argument>)")
	 (1 "((FLET SB-C::LOOKUP) (#<SB-C::VOLATILE-INFO-ENV \"Working\">
#<SB-C::COMPACT-INFO-ENV #1=\"Auxiliary\"> #<SB-C::COMPACT-INFO-ENV
#1#>))")
	 (2 "(MACRO-FUNCTION #<error printing object>)")
	 (3 "(SWANK::SYMBOL-INDENTATION #<error printing object>)")
	 (4 "((FLET SWANK::CONSIDER) #<error printing object>)")
	 (5 "((FLET SB-IMPL::ITERATE-OVER-HASH-TABLE)
#<SB-IMPL::PACKAGE-HASHTABLE :SIZE 95 :FREE 36 :DELETED 0>)")
	 (6 "(SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS #<HASH-TABLE :TEST EQ
:COUNT 124 {14004AC1}> (#<PACKAGE \"SWANK-IO-PACKAGE\"> #<PACKAGE
\"SWANK\"> #<PACKAGE \"SWANK-MOP\"> #<PACKAGE \"SWANK-BACKEND\">
#<PACKAGE \"SWANK-LOADER\"> #<PACKAGE \"WEBLOCKS-ASD\"> ...))")
	 (7 "(SWANK::PERFORM-INDENTATION-UPDATE #<SWANK::CONNECTION
{14004B11}> (#<PACKAGE \"SWANK-IO-PACKAGE\"> #<PACKAGE \"SWANK\">
#<PACKAGE \"SWANK-MOP\"> #<PACKAGE \"SWANK-BACKEND\"> #<PACKAGE
\"SWANK-LOADER\"> #<PACKAGE \"WEBLOCKS-ASD\"> ...))")
	 (8 "(SWANK::RUN-HOOK (SWANK::SYNC-INDENTATION-TO-EMACS
SWANK::SYNC-FEATURES-TO-EMACS))")
	 (9 "((LAMBDA NIL))")
	 (10 "((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {1410E8B5}>)")
	 (11 "((LAMBDA NIL))")
	 (12 "((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {13E2D9F5}>)")
	 (13 "(SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {14004B11}>
#<CLOSURE (LAMBDA NIL) {1410E77D}>)")
	 (14 "(SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {14004B11}>
#<FUNCTION (LAMBDA NIL) {13E2D9F5}>)")
	 (15 "(SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {14004B11}>)")
	 (16 "(SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {1410E75D}>)")
	 (17 "((FLET SB-THREAD::WITH-MUTEX-THUNK))")
	 (18 "(SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS #<CLOSURE (FLET
SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {4D01C2D}> T)")
	 (19 "((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)"))

Which not only tells us that the error occurs while Slime is updating
identation information, we also (quite accidentally) learn that
something is amiss: in frame 7 we see "WEBLOCKS-ASD" which is
definitely not part of the normal SBCL distribution... and likely
there are others as well. Either this is a custom core, or you do have
either .sbclrc, or  /etc/sbclrc.

Additionally, from the MACRO-FUNCTION & LOOKUP frames I can tell that
somehow you have, in some package, a symbol whose name is not a string
but a number. This is quite an achievement. :) Constructing a bogus
symbol like that is not too hard (SAFETY 0 and lying to the compiler
can do it), but getting them interned into a package is a lot harder
-- I cannot think of a simple mistake that could cause that even in
SAFETY 0 code. In other words, something is probably badly wrong with
the image even before Slime starts.

Where do the extra packages like Weblocks come from? Once you know
that, does the same error occur if you start without them?

Cheers,

 -- Nikodemus