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

[Maciej Katafiasz]

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.

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.

Hope this helps,
Maciej