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

Gary Byers gb at clozure.com
Sun Dec 5 22:18:46 UTC 2004



On Sun, 5 Dec 2004 rm at fabula.de wrote:

>
> On Sat, Dec 04, 2004 at 12:11:48PM -0600, Rick Taube wrote:
> > >Now, i can load and start the examples but unfortunately the first
> > >callback
> > >seems to tickle openmcl's kernel in unwanted places. I guess i should
> > >first
> > >test my gtk2 bindings without the lambdagtk suggar ... :-/
> >
> > sorry i dont know anything about the callback support on linux-ppc, ive
> > only used the darwin version and that works quite well
>
> Hello Rick,
>
> here's what i've done so far (i'll send a cc tothe openmcl-devel list, i
> fear i need some help from there).
>
>
>  - created a (hopefully correct) populate.sh that uses 'pkg-config' to
>    find all neccessary CPP flags.
>
>  - generated the interface database as outlined on the website
>
>  - rewrote 'ccl:library/openmcl-gtk-support.lisp' into 'ccl:library/openmcl-gtk2-support.lisp'
>    (BTW, is the installation of the gtk-task with def-load-pointers really neccessary?
>     Is there no better way to run the gtk-main loop in a dedicated thread?).
>

That example's extremely old; in the old (OpenMCL <= 0.13) cooperatively-
scheduled days, running GTK+ (or Cocoa, or ...) event loops a little at
at time in a periodic task was about the only way to run them at all.

If you do:

? (process-run-function "GTK Event Loop" #'(lambda () (#_gtk_main ...)))

does it still crash ?  [OK, I read what you say below, and I guess
that it does.]

I think that once the cause of the crash is determined you'd want
to just run the GTK event loop (and all callbacks) in a dedicated
thread.

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 ?


>  - wrote a quick test case as follows:
>
>
> ;;; ---- File ffi-test-gtk2.lisp ---------------------------------------------------------
>
> (eval-when (:compile-toplevel :execute)
>   (require "openmcl-gtk2-support"))
>
> (defcallback button-clicked
>     (:address button :address cmd :void)
>   (declare (ignore button cmd))
>   (format t "Hello stranger ~%"))
>
> (defcallback action-quit (:address widget :address data :void)
>   (declare (ignore widget))
>   (format t "Oi veh ...~%")
>   (#_gtk_main_quit))
>
> (defun gtk2-test ()
>
>     (let ((window (#_gtk_window_new #$GTK_WINDOW_TOPLEVEL))
> 	  (button (#_gtk_button_new)))
>
>       (with-cstrs ((destroy-name  "destroy")
> 		   (clicked-name  "clicked")
> 		   (window-title  "Mompidomp ...")
> 		   (button-label  "Click me, stranger ..."))
> 	(#_gtk_window_set_title window window-title)
> 	(#_gtk_button_set_label button button-label)
> 	(#_g_signal_connect_data button clicked-name button-clicked button (%null-ptr) 0)
> 	(#_g_signal_connect_data window destroy-name action-quit window (%null-ptr) 0))
>
>       (#_gtk_container_add window button)
>       (#_gtk_widget_show button)
>       (#_gtk_widget_show window)
>
>       (ccl::%install-periodic-task 'gtk2-task
> 				   #'(lambda ()
> 				       (do* ()
> 					    ((eql (#_gtk_events_pending) 0))
> 					 (#_gtk_main_iteration)))
> 				   10)))
>
> ;;;; -------------- File ends here --------------------------------------------------
>
> NOTE: i installed the periodic task here since i haven't put it into my gtk2-support
> and i wnated to test whether gtk-main was causing the troubles (same effect with
> gtk-man and the periodic task, i'm affraid).
>
> Now, as with the lambda-gtk code, everything works fine until the first callback
> arrives ... here's a kernel backtrace:
>
>   Welcome to OpenMCL Version (Beta: Linux) 0.14.2!
>   ? (load "ffi-test-gtk2.lisp")
>
>   "Loading libraries ..."
>   " ... Done"
>   ;Compiler warnings :
>   ;   Unused lexical variable DATA, in ACTION-QUIT.
>   #P"/usr/local/src/LISP/lambda-gtk-0.1/ffi-linux.lisp"
>   ? (gtk2-test)
>   #<PERIODIC-TASK GTK2-TASK 10 #x353B58A6>
>   ? Unhandled exception 11 at 0x00012c78, context->regs at #x7fffdd50
>   Read operation to unmapped address 0x7f454c44
>    In foreign code at address 0x00012c78
>   ? for help
>   [8158] OpenMCL kernel debugger: b
>
>
>   (#x7fffe210) #x00013688 : (null) + 79496
>   (#x7fffe240) #x0001381C : (null) + 79900
>   (#x7fffe480) #x300E4BD4 : (null) + 806243284
>   (#x7FFFE4B0) #x7FFFE808 : foreign code (unknown)
>   (#x7fffeb00) #x0F8E3AC4 : (null) + 260979396
>   (#x7fffebc0) #x0F8E29EC : g_signal_emit_valist + 1864
>   (#x7fffee10) #x0F8E2D38 : g_signal_emit + 108
>   (#x7fffeea0) #x0F015628 : gtk_button_clicked + 132
>   (#x7fffeec0) #x0F016804 : (null) + 251750404
>   (#x7fffeee0) #x0F8E405C : g_cclosure_marshal_VOID__VOID + 176
>   (#x7fffef00) #x0F8CE930 : (null) + 260892976
>   (#x7fffef30) #x0F8CE5A4 : g_closure_invoke + 224
>   (#x7fffef70) #x0F8E3374 : (null) + 260977524
>   (#x7ffff030) #x0F8E29EC : g_signal_emit_valist + 1864
>   (#x7ffff280) #x0F8E2D38 : g_signal_emit + 108
>   (#x7ffff310) #x0F015568 : gtk_button_released + 132
>   (#x7ffff330) #x0F016618 : (null) + 251749912
>   (#x7ffff350) #x0F0D62F0 : _gtk_marshal_BOOLEAN__BOXED + 212
>   (#x7ffff380) #x0F8CE930 : (null) + 260892976
>   (#x7ffff3b0) #x0F8CE5A4 : g_closure_invoke + 224
>   (#x7ffff3f0) #x0F8E3470 : (null) + 260977776
>   (#x7ffff4b0) #x0F8E27B0 : g_signal_emit_valist + 1292
>   (#x7ffff700) #x0F8E2D38 : g_signal_emit + 108
>   (#x7ffff790) #x0F1DBEE8 : (null) + 253607656
>   (#x7ffff7b0) #x0F0D4670 : gtk_propagate_event + 268
>   (#x7ffff7d0) #x0F0D3118 : gtk_main_do_event + 652
>   (#x7ffff800) #x0F96965C : (null) + 261527132
>   (#x7ffff820) #x0F9DAC98 : (null) + 261991576
>   (#x7ffff870) #x0F9DC1DC : g_main_context_dispatch + 232
>   (#x7ffff890) #x0F9DC5AC : (null) + 261997996
>   (#x7ffff8d0) #x0F9DC8B0 : g_main_context_iteration + 132
>   (#x7ffff8f0) #x0F0D2AE0 : gtk_main_iteration + 60
>   (#x7ffff910) #x00007BE0 : (null) + 31712
>   (#x7FFFF918) #x353BF980 : #<Anonymous Function #x353bf9be> + 52
>   (#x7FFFF928) #x311143D0 : #<Function HOUSEKEEPING #x3512b42e> + 452
>   (#x7FFFF938) #x31114358 : #<Function HOUSEKEEPING #x3512b42e> + 332
>   (#x7FFFF948) #x311142C8 : #<Function HOUSEKEEPING #x3512b42e> + 188
>   (#x7FFFF958) #x310F7F6C : #<Anonymous Function #x350f7afe> + 312
>   (#x7FFFF968) #x310F7F84 : #<Anonymous Function #x350f7afe> + 336
>   (#x7FFFF978) #x310F7F8C : #<Anonymous Function #x350f7afe> + 344
>   (#x7FFFF988) #x310F7FC0 : #<Anonymous Function #x350f7afe> + 396
>   (#x7FFFF998) #x00008820 : (subprimitive (null))
>
>
>  ... more follows but didn't look to relevant.
>
> Hmm, i don't really know where to go now. Maybe one of the OpenMCL
> gurus has some idea/pointer?
>
>
> > >Oh, and as a suggestion: i'd be rather cool to have libglade support in
> > >lambda-gtk. Saves a _lot_ of typing ...
> >
> > there was a post about this on Planet Lisp last month, I think this is
> > the one:
> >
> > http://journal.boblycat.org/musings/archives/000144.html
>
> Ah, missed that. That does look very promissing :-)
>
>  TIA Ralf Mattes
>
>
> ----- End forwarded message -----
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list