Re: libseed-list bug with threads and closures?

["Alan Knowles" <alan akbkhome com>]

Have a look at scope="call" - in and around that definition. It's probably also worth looking at timeout_add and see how the gir definition of that differs from thread_create.

>From my nightmares with thread programming, where it segfaults, and even the backtraces tend to be of little use...

usually more of a try and hope style fixing technique..

Regards
Alan


 --- On 03/Aug/2010, Jonatan Liljedahl wrote: 
> On 08/03/2010 01:39 AM, Alan Knowles wrote:
> > Avoid threads is normally the answer ;)
> 
> If one wants life to be simple, yes ;)
> But with todays multicore machines, threads is a must.
> 
> > have you had a play with the transfer ownership stuff..
> >
> > = this is the thread_create_full first argument - it's tranfer none, which in theory
> > means that the function is available for gc after the method is called.
> >
> >        <parameters>
> >          <parameter name="func"
> >                     transfer-ownership="none"
> >                     scope="call"
> >                     closure="1">
> >            <type name="ThreadFunc" c:type="GThreadFunc"/>
> >          </parameter>
> 
> Yes, but I think JSValueProtect() is called on it somewhere..
> Also, storing it in a global variable didn't help:
> 
> var f;
> ...
> GLib.thread_create_full(f=function() { ...
> 
> Also it fails in different ways each time, so it's clearly a memory-bug 
> of some kind. Sometimes it even says that variables are missing in the 
> thread-function or idle-function, before it crashes.
> 
> /Jonatan
> 
> > Regards
> > Alan
> >
> >   --- On 02/Aug/2010, Jonatan Liljedahl wrote:
> >> Any ideas on this? I'm stuck.. Hoping someone with more insight in
> >> closures and gobject-introspection might help.
> >>
> >> /Jonatan
> >>
> >> On 07/28/2010 04:06 PM, Jonatan Liljedahl wrote:
> >>> This simple code crashes (output and stacktrace at the end of this
> >>> mail). I don't see why it shouldn't work. GLib.idle_add() is the
> >>> recommended way to defer stuff from a thread to the mainloop and I've
> >>> used it several times in C code.
> >>>
> >>> Seems to be a problem with closures, threads and the garbage collector?
> >>>
> >>> /////////// thread_bugs.js ////////////
> >>> var Gtk = imports.gi.Gtk;
> >>> Gtk.init(0,0);
> >>>
> >>> var w = new Gtk.Window({border_width: 20});
> >>> var b = new Gtk.Button({label: "Foo"});
> >>> w.add(b);
> >>> w.show_all();
> >>>
> >>> b.signal.clicked.connect(function() {
> >>> print("Clicked");
> >>> GLib.thread_create_full(function() {
> >>> print("Thread start");
> >>> var i=0;
> >>> var x=1.3;
> >>> for(i=0;i<9999999;i++) {
> >>> x *= 1.000004;
> >>> };
> >>> print(x);
> >>> print("Dispatch to mainloop");
> >>> GLib.idle_add(GLib.PRIORITY_DEFAULT_IDLE,function() {
> >>> print("In mainloop");
> >>> b.label = "Bar"+x;
> >>> return false;
> >>> });
> >>> },null,0,true);
> >>> });
> >>>
> >>> Gtk.main();
> >>> //////////// EOF /////////////
> >>>
> >>> Clicked
> >>>
> >>> ** (seed:2184): WARNING **: ArgumentError - probably due to incorrect
> >>> gir file (which may be fixed upstream) argument 2 must not be null for
> >>> function: thread_create_full
> >>>
> >>> [New Thread 0xb57d8b70 (LWP 2188)]
> >>> Thread start
> >>> 3.05975143636762e+17
> >>> Dispatch to mainloop
> >>> In mainloop
> >>>
> >>> Program received signal SIGSEGV, Segmentation fault.
> >>> 0x00cdbd12 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> (gdb) bt
> >>> #0 0x00cdbd12 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #1 0x00cdc8a4 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #2 0x00cdc905 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #3 0x00cdd845 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #4 0x00cde4f0 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #5 0x00be63b3 in JSGlobalContextRelease () from /usr/lib/libwebkit-1.0.so.2
> >>> #6 0x00137bb6 in seed_handle_closure (cif=0x81ccc00, result=0xbfffec38,
> >>> args=0xbfffebd0, userdata=0x81cb7e8) at seed-closure.c:290
> >>> #7 0x003aa316 in ?? () from /usr/lib/libffi.so.5
> >>> #8 0x003aa6fa in ?? () from /usr/lib/libffi.so.5
> >>> #9 0x00301151 in ?? () from /lib/libglib-2.0.so.0
> >>> #10 0x00303165 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
> >>> #11 0x00306f88 in ?? () from /lib/libglib-2.0.so.0
> >>> #12 0x003074c7 in g_main_loop_run () from /lib/libglib-2.0.so.0
> >>> #13 0x0132c3c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> >>> #14 0x003aa63f in ffi_call_SYSV () from /usr/lib/libffi.so.5
> >>> #15 0x003aa46f in ffi_call () from /usr/lib/libffi.so.5
> >>> #16 0x0039c799 in g_function_info_invoke ()
> >>> from /usr/lib/libgirepository-1.0.so.0
> >>> #17 0x0013bb4a in seed_gobject_method_invoked (ctx=0xb636e098,
> >>> function=0xb5f3be80, this_object=0xb6338ac0, argumentCount=0,
> >>> arguments=0xbffff0d0, exception=0xbffff11c) at seed-engine.c:656
> >>> #18 0x00be20be in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> ---Type<return>  to continue, or q<return>  to quit---
> >>> #19 0x00c28f1a in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #20 0x02614236 in ?? ()
> >>> #21 0x00c3a7ce in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #22 0x00cf5b66 in ?? () from /usr/lib/libwebkit-1.0.so.2
> >>> #23 0x00bdc4a9 in JSEvaluateScript () from /usr/lib/libwebkit-1.0.so.2
> >>> #24 0x0013860c in seed_evaluate (ctx=0xb67a2e24, s=0x80579c0, this=0x0)
> >>> at seed-api.c:279
> >>> #25 0x08048f01 in seed_exec (filename=0xbffff64c "thread_bugs.js") at
> >>> main.c:95
> >>> #26 0x08049134 in main (argc=2, argv=0xbffff4c4) at main.c:161
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list