Hi,
Today I observed a rather nasty interaction that I'm at a loss to explain. If I wrap the CLIM Debugger around an Emacs-Style Application which uses mcclim-freetype, and provoke an entry into that debugger, I get X Length Errors. I think I need all three of those elements: the clim debugger and listener work fine together; gsharp and the clim debugger without freetype work fine; and of course the applications work acceptably using freetype in normal operation and with slime.
I am not sure whether this is specific to SBCL; nor am I sure whether it is specific to threaded lisps; I haven't tried it with a non-threaded system. The event queue process has a backtrace that looks like
Backtrace: (BACKTRACE-AS-LIST 200) (DEBUGGER-HOOK #<XLIB:LENGTH-ERROR {10060EA641}> #) (INVOKE-DEBUGGER #<XLIB:LENGTH-ERROR {10060EA641}>) (CERROR "Ignore" XLIB:LENGTH-ERROR) (XLIB::X-CERROR "Ignore" XLIB:LENGTH-ERROR :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :ERROR-KEY XLIB:LENGTH-ERROR :ASYNCHRONOUS T :CURRENT-SEQUENCE 1913 :MAJOR 154 :MINOR 25 :SEQUENCE 1563) [...] (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :HANDLER # :TIMEOUT NIL :PEEK-P NIL :DISCARD-P T :FORCE-OUTPUT-P T) ((SB-PCL::FAST-METHOD CLIM-BACKEND:GET-NEXT-EVENT #) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 {10059661F1}> (:WAIT-FUNCTION NIL :TIMEOUT NIL))
while the application thread (which /also/ gets a length error) has a backtrace involving HANDLE-REPAINT on the menu-button-pane of the CLIM Debugger, CLIM-CLX::FONT-DRAW-GLYPHS (MCCLIM-FREETYPE::FREETYPE-FACE ...), and a call to XLIB::DRAWABLE-DEPTH and XLIB::READ-REPLY.
Any ideas? Can anyone replicate any of this? Is there something in the toplevel loop of ESA (or attendant methods) which could cause this problem?
Cheers,
Christophe