[Openmcl-devel] Re: [lambda-gtk-devel] Bug in examples.lisp

[rm at fabula.de]

On Sun, Dec 05, 2004 at 03:18:46PM -0700, Gary Byers wrote:

> Note that GTK2 is supposed to be "thread aware, but not thread-safe";
> IIRC, there's a global lock that any thread that touches a GTK data
> structure has to acquire before doing so.  The exact mechanism it's
> supposed to use is buried in several C preprocessor macros; I think
> that I once decoded them and found the actual locking primitive and
> how to find the actual lock object, but didn't write that down ...
> 
> In any case: I can't tell too much from the backtrace below.
> What would I need to do to be able to reproduce this ?

Sorry for my late response but i had other work to do. I just
spent some time trying to narrow down the problem. Right now
i compiled my own library and implemented callback registration
and invokation. Unfortunately (?) the callback mechanism seems to
work fine with my dynamic library - so i guess i have to look closer
at the gtk2 side. The callback registration _is_ a place where a lot
of things changed from gtk-1.2 to gtk-2.0. Here's a kernel backtrace:

  ? Unhandled exception 11 at 0x00012c78, context->regs at #x30d94cb0
  Read operation to unmapped address 0x7f454c44
   In foreign code at address 0x00012c78
  ? for help
  [28607] OpenMCL kernel debugger: b
   
   
  (#x30d95170) #x00013688 : (null) + 79496
  (#x30d951a0) #x0001381C : (null) + 79900
  (#x30d953e0) #x300E4BD4 : (null) + 806243284
  (#x30D95410) #x30D95768 : foreign code (unknown)
  (#x30d95a60) #x3093E7DC : (null) + 814999516
  (#x30d95b20) #x3093D980 : g_signal_emit_valist + 1864
  (#x30d95d70) #x3093DCCC : g_signal_emit + 108
  (#x30d95e00) #x0F015628 : gtk_button_clicked + 132
  (#x30d95e20) #x0F016804 : (null) + 251750404
  (#x30d95e40) #x3093EFF0 : g_cclosure_marshal_VOID__VOID + 176
  (#x30d95e60) #x309298C4 : (null) + 814913732
  (#x30d95e90) #x30929538 : g_closure_invoke + 224
  (#x30d95ed0) #x3093E308 : (null) + 814998280
  (#x30d95f90) #x3093D980 : g_signal_emit_valist + 1864
  (#x30d961e0) #x3093DCCC : g_signal_emit + 108
  (#x30d96270) #x0F015568 : gtk_button_released + 132
  (#x30d96290) #x0F016618 : (null) + 251749912
  (#x30d962b0) #x0F0D62F0 : _gtk_marshal_BOOLEAN__BOXED + 212
  (#x30d962e0) #x309298C4 : (null) + 814913732
  (#x30d96310) #x30929538 : g_closure_invoke + 224
  (#x30d96350) #x3093E404 : (null) + 814998532
  (#x30d96410) #x3093D744 : g_signal_emit_valist + 1292
  (#x30d96660) #x3093DCCC : g_signal_emit + 108
  (#x30d966f0) #x0F1DBEE8 : (null) + 253607656
  (#x30d96710) #x0F0D4670 : gtk_propagate_event + 268
  (#x30d96730) #x0F0D3118 : gtk_main_do_event + 652
  (#x30d96760) #x0F96965C : (null) + 261527132
  (#x30d96780) #x309A9DBC : (null) + 815439292
  (#x30d967d0) #x309AB300 : g_main_context_dispatch + 232
  (#x30d967f0) #x309AB6D0 : (null) + 815445712
  (#x30d96830) #x309ABEDC : g_main_loop_run + 588
  (#x30d96860) #x0F0D281C : gtk_main + 232
   
Is there a way to set breakpoints on the trampoline function? Or at least 
to get the address of it? I'm pretty new to LISP implementations so i don't
really know how to drill down my test cases any more - i might try to overload
g_signal_emit_valist  to inspect what's going on from the C side.

 TIA 
    Ralf Mattes