[Openmcl-devel] Re: [lambda-gtk-devel] Bug in examples.lisp
Gary Byers
gb at clozure.com
Sun Dec 5 14:18:46 PST 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