[cl-gtk2-devel] debugging cl-gtk applications

[Kalyanov Dmitry]

On Wed, 2011-08-24 at 15:25 +0200, Maciej Katafiasz wrote:
> On Wed, Aug 24, 2011 at 02:02, Peter Keller <psilord at cs.wisc.edu> wrote:
> > When I use cl-gtk with sbcl, sometimes I write a bug where I define a
> > slot with an incorrect signature.
> >
> > What SBCL does at this point is that the thread containing the wrong code
> > dumps a message (usually "wrong number of arguments 2", etc being the
> > entirety of it even with debug and safety at 3 and speed optimize at 0)
> > and stops, but the REPL apparently doesn't notice.
> >
> > So, I then have this stopped thread hanging out in the background. How
> > does one access the correct thread to figure out a backtrace for the
> > failure?
> 
> Which platform are you using? There are two things to consider here:
> 
> 1) Win32 threading support is still pretty experimental, and there are
> many things from the surrounding assumptions (such as signal handling
> and the lack thereof on Windows, coupled with the fact that SLIME
> sends C-c on break request, which will kill SBCL because it doesn't
> register a proper Win32 handler( that simply haven't been updated to
> match Win32. The introspection bits can also be somewhat subpar
> compared to Linux, which will hurt you when trying to determine a
> non-obvious crash. That said, I've had quite good results getting GTK+
> to work on Win32, and that's including breaking and debugger
> signalling.

Actually, threading on Windows works quite fine (either in my SBCL fork
(which is now outdated) or in Anton Kovalenko's (which is more
up-to-date)). You would have to use fresh and patched libraries (namely,
SLIME, Usocket needed patching - at least when I looked at them last
time) and configure SLIME to use :spawn communication model. Then you'll
be able to use debugger and interrupt threads.

> 
> 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.
> Perhaps trying the same on CCL instead could help in the short term,
> but I must admit that I've only thought about migrating my code to
> CCL, not actually done so. Another not-really workaround is to restart
> SBCL and make sure you only run the suspect on a completely fresh
> image, *once*. If you do go down that route, you really, really want
> to SAVE-LISP-AND-DIE with as much of everything preloaded as possible.

I've responded to this on SBCL's list, but I'll reply also here.

This seems like an issue in cl-gtk2 that was fixed quite some time ago.
It boils down to the fact that Gtk+ messes with POSIX signal handlers
(http://developer.gnome.org/gtk/2.24/gtk-General.html#gtk-init says that
"GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, to ignore
SIGPIPE signals"). It was worked around in cl-gtk2.