On Mon, May 19, 2008 at 4:58 AM, Aaron Feng aaron.feng@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