Steel Bank Common Lisp

On 24 August 2011 18:28, Peter Keller <psilord@...> wrote:

> I find that often (maybe 100% reproducable), when I write a slot handler
> for a gtk signal with an incorrect lambda-list and run the software,
> I get what appears to be a debugger break in a thread with an error
> message like "wrong arguments 2"...and then nothing. The REPL thread
> doesn't seem to notice and if I break the REPL into the debugger again,
> I have no idea how to access the other threads. No matter what settings
> I use for debug/safty/optimize I can't get any better error message than
> that or a backtrace in the offending thread.

Is the in the terminal?

If so, the thread with the error is probably waiting for the terminal.
(The current mechanism that mediates this is ... not the nicest.)

Here's an example, ;;; are my comments.

* (defvar *th* (make-thread (lambda () (error "My bad!")) :name "Oops"))

*TH*
*
;;; This is the other thread barfing. It is now waiting for access to the
;;; terminal.
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "Oops" RUNNING
                                                {1003112AB1}>:
  My bad!
;;; We're still in the original thread, though.
*th*

#<THREAD "Oops" RUNNING {1003112AB1}>
* *current-thread*

#<THREAD "initial thread" RUNNING {1002939071}>
;;; But we can release the terminal to allow us to debug the other thread.
* (release-foreground)

Resuming thread #<THREAD "Oops" RUNNING {1003112AB1}>

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Oops" RUNNING
                        {1003112AB1}>)

((LAMBDA ()))0
0] ba

0: ((LAMBDA ()))
1: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK443]448))
2: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
3: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]309))
4: (SB-THREAD::CALL-WITH-MUTEX
    #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {322BD09}>
    #<MUTEX "thread result lock" owner: #<THREAD "Oops" RUNNING {1003112AB1}>>
    #<THREAD "Oops" RUNNING {1003112AB1}>
    T)
5: (SB-THREAD::INITIAL-THREAD-FUNCTION)
6: ("foreign function: call_into_lisp")
7: ("foreign function: new_thread_trampoline")
8: ("foreign function: _pthread_start")
9: ("foreign function: thread_start")

0] 0
Resuming thread #<THREAD "initial thread" RUNNING {1002939071}>

* *th*

#<THREAD "Oops" ABORTED {1003112AB1}>

>> 2) On Linux there's currently an undetermined SBCL bug which somehow
>> manifests itself very often in presence of semi-complex CL-GTK2 code.
>> The end result is that after the first time the offending code is
>> executed, thread handling fails silently and catastrophically,
>> including the complete inability to interrupt other threads (which
>> also precludes the debugger from noticing anything going wrong). It's
>> very possible that you're seeing this. In this case, there's not much
>> to be done except a long and torturous debugging session to fix SBCL.

This is the first I hear of this.

Information how how to reproduce this would be most welcome.

I have two theories as to what might cause something that vaguely
resembles the description:

 * GC deadlock. If CL-GTK uses WITHOUT-GCING anywhere, then all locks it
   obtains while in WITHOUT-GCING code must only ever be held while inside
   WITHOUT-GCING. (Moral: don't use WITHOUT-GCING unless you really have to,
   and then seriously try to minimize the amount of things done there.)

 * Foreign threads calling into Lisp. This is not currently supported at
   all. Only threads created using MAKE-THREAD can call into Lisp.

> What do the SBCL folks recommend I do so I can figure out how to debug these
> errors? How do I (in general) access different threads from the debugger?

I have no experience with CL-GTK2, but unless it is violently
Slime-unfriendly, using it with Slime might make your life easier.

Cheers,

 -- Nikodemus

Crowdfunding SBCL: http://www.indiegogo.com/SBCL-Threading-Improvements-1

On Wed, 2011-08-24 at 19:30 +0300, Nikodemus Siivola wrote:
> On 24 August 2011 18:28, Peter Keller <psilord@...> wrote:
> 
> >> 2) On Linux there's currently an undetermined SBCL bug which somehow
> >> manifests itself very often in presence of semi-complex CL-GTK2 code.
> >> The end result is that after the first time the offending code is
> >> executed, thread handling fails silently and catastrophically,
> >> including the complete inability to interrupt other threads (which
> >> also precludes the debugger from noticing anything going wrong). It's
> >> very possible that you're seeing this. In this case, there's not much
> >> to be done except a long and torturous debugging session to fix SBCL.
> 
> This is the first I hear of this.
> 
> Information how how to reproduce this would be most welcome.

Actually, it seems like an issue in cl-gtk2 that was fixed a long time
ago (I don't know why it reappeared - I haven't looked into it yet). The
issue was that Gtk+ changes signal handlers:

  "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during
initialization, to ignore SIGPIPE signals, since these are almost never
wanted in graphical applications. If you do need to handle SIGPIPE for
some reason, reset the handler after gtk_init(), but notice that other
libraries (e.g. libdbus or gvfs) might do similar things."

 (from http://developer.gnome.org/gtk/2.24/gtk-General.html#gtk-init )

Since SBCL uses SIGPIPE for thread interruption, setting SIGPIPE to
SIG_IGN breaks it. cl-gtk2 works around this by reenabling SIGPIPE after
gtk_init
(https://github.com/dmitryvk/cl-gtk2/commit/f6d4e6c74f4490bed63810a07587a0a63fd8c394)

> 
> I have two theories as to what might cause something that vaguely
> resembles the description:
> 
>  * GC deadlock. If CL-GTK uses WITHOUT-GCING anywhere, then all locks it
>    obtains while in WITHOUT-GCING code must only ever be held while inside
>    WITHOUT-GCING. (Moral: don't use WITHOUT-GCING unless you really have to,
>    and then seriously try to minimize the amount of things done there.)
> 
>  * Foreign threads calling into Lisp. This is not currently supported at
>    all. Only threads created using MAKE-THREAD can call into Lisp.

cl-gtk2 does none of this, so this should not be a problem.

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.

Thank you.

-pete