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
Christophe Rhodes csr21@cam.ac.uk writes:
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
The good (?) news is that this also happens in a non-threaded system; that's not really good news, but it does mean that some attempt at understanding this can be made without the added extra confusion of race conditions and threads.
I attach a backtrace. Com-error is a command I defined at the M-: climacs "repl" and bound to C-! as follows
(climacs-gui::define-climacs-command com-error () (error "foo")) (esa:set-key 'com-error 'clim:global-command-table '((#! :control))) (esa:set-key 'com-error 'clim:global-command-table '((#! :control :shift)))
I /think/ I have seen this symptom once before, and it had something to do with CLX not being re-entrant: something somewhere was attempting to call a protocol request in the dynamic scope of another one. I can't remember the details: neither how I debugged it nor what I did to fix it :-(
Any ideas?
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
Any ideas?
Moments later, Andreas (our intrepid release manager) provided a hint. It's possible to trigger length errors by typing long (about 200 character) strings at a clim-listener or beirc prompt when using mcclim-freetype. By altering the clim-debugger only to print the first 80 characters of each frame, the length error symptoms go away, so I presume that there is a very long frame in the backtrace of an ESA, where there isn't in the clim-listener.
This might point out a need to implement BIG-REQUESTS for CLX... any takers?
Cheers,
Christophe
--- Christophe Rhodes csr21@cam.ac.uk wrote:
This might point out a need to implement BIG-REQUESTS for CLX... any takers?
You might want to take a look at this:
http://article.gmane.org/gmane.lisp.clx.devel/108
Not sure if it is in the current telent-clx or not.
Cheers, CY
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-
C Y -
Christophe Rhodes