On Wed, Aug 24, 2011 at 07:30:30PM +0300, Nikodemus Siivola wrote:
> Is the in the terminal?
yes. SBCL running in an xterm.
> ;;; But we can release the terminal to allow us to debug the other thread.
> * (release-foreground)
This works just fine and I am _finally_ able to get the backtrace I need.
Thank you very much!
> Information how how to reproduce this would be most welcome.
I've attached a reasonably small example which shows the problem.
The line of code with the error on it is near "XXX THIS IS THE BUG" comment.
You will see that the lambda-list is wrong.
To reproduce the problem, unpack the attached tarball, have quicklisp
installed. Make sure these are installed and they work from quicklisp:
(The last one in this list might take some futzing to work since it isn't
enabled by default in quicklisp but is available in quicklisp's cl-gtk2)
#:cl-opengl #:cl-glu #:lispbuilder-sdl #:cl-gtk2-gtk #:cl-gtk2-gtkglext
Then, run the software by (require :test-1) (in-package :test-1)
(doit), you should see a rotating square. Put the mouse into the opengl
buffer, and hit a single key. Then you should see that the gtk main
thread emits an error, but there is no keyboard response. Then, Ctrl-C,
abort--returning to toplevel, then type (sb-thread:release-foreground),
and finally you get something very meaningful in terms of debugging
information and backtrace ability.
However, if you then terminate the thread, the busted gtk window stays up.
If you run (doit) again, it just sits there, doing nothing and not
consuming any CPU.
At this point in time, I have to tear down the SBCL session and restart
it since it just seems broken. As far as I am concerend, I aborted both
the gtk main thread and the original call to doit, so I should be able
to restart the program and have it work.