Re: Threads and Gtk2

[muppet <scott asofyet org>]

On Oct 20, 2005, at 6:26 PM, Javier Godinez wrote:

> I think I am not freeing up something that I sholuld, any takers?

Looks more like the VMware module is freeing something that has  
already been freed.

Not a Gtk2-Perl bug.


> Here is my backtrace:
...
> #4  0xb7ec3275 in free () from /lib/tls/i686/cmov/libc.so.6
> #5  0xb71a69f8 in VMControlAuthDestroyConnectParams (s=0x86be550)
>     at /build/mts/release/bora-14497/bora/lib/vmcontrol/ 
> vmcontrolAuth.c:518
> #6  0xb71aa210 in VMControl_VMDestroy (vm=0x86c6bf0)
>     at /build/mts/release/bora-14497/bora/lib/vmcontrol/ 
> vmcontrolVM.c:640
> #7  0xb718933b in XS_VMware__VmPerl__VM_DESTROY ()
>    from /usr/local/lib/perl/5.8.7/auto/VMware/VmPerl/VmPerl.so

This is in the VMware module.  Specifically, it's  
VMware::VmPerl::DESTROY (strip the ^XS_, replace __ with ::, and it  
looks like they've set PREFIX=VM_.  The module doesn't appear to be  
available anywhere on the 'net (well, not for someone who isn't a  
VMware customer, at least).

DESTROY xsubs typically are used to destroy the memory pointed by  
objects blessed into that class.  As we can see, VM_DESTROY is  
calling VMControl_VMDestroy, which tries to destroy the connection  
parameters, which have already been freed.


> #8  0x080c406d in Perl_pp_entersub ()
> #9  0x08060cfd in Perl_get_cv ()
> #10 0x080646ee in Perl_call_sv ()
> #11 0x080c6a4d in Perl_sv_clear ()
> #12 0x080c7253 in Perl_sv_free ()
> #13 0x080c59d3 in Perl_sv_add_arena ()
> #14 0x080c5a1f in Perl_sv_clean_objs ()
> #15 0x08066484 in perl_destruct ()
> #16 0xb7003517 in Perl_ithread_destruct ()
>    from /usr/lib/perl/5.8/auto/threads/threads.so
> #17 0xb7003929 in ithread_mg_free ()
>    from /usr/lib/perl/5.8/auto/threads/threads.so
> #18 0x080c742e in Perl_sv_unmagic ()
> #19 0xb7004a9a in Perl_ithread_DESTROY ()
>    from /usr/lib/perl/5.8/auto/threads/threads.so
> #20 0xb7005538 in XS_threads_DESTROY ()
>    from /usr/lib/perl/5.8/auto/threads/threads.so
> #21 0x080c406d in Perl_pp_entersub ()
> #22 0x08060cfd in Perl_get_cv ()
> #23 0x080646ee in Perl_call_sv ()
> #24 0x080c6a4d in Perl_sv_clear ()
> #25 0x080c7253 in Perl_sv_free ()
> #26 0x080c59d3 in Perl_sv_add_arena ()
> #27 0x080c5a1f in Perl_sv_clean_objs ()
> #28 0x08066484 in perl_destruct ()
> #29 0x0805fd9a in main ()

This bit says that it's not Gtk2::main_quit's fault; Gtk2::main_quit  
merely gets you out of the main loop, and after that, the program  
goes on to exit normally.  perl_destruct() is where perl finalizes  
the interpreter and all of the perl objects that are still alive.

One of the objects that's still alive is apparently a reference to a  
thread, so that thread is also going through a destruction cycle.   
From your code posted earlier, i'm going to guess thats $thr1.


I don't know how VMware's API works, but i'm willing to bet that  
what's happening here goes like this:

1. main program creates a VMware object, and attaches a perl wrapper  
to it.
2. main program creates a new thread; when the interpreter is cloned,  
its memory space is, as well, so the underlying object winds up  
having two scalars pointing at it.
3. in cleanup, both of the perl scalars pointing to the VMware object  
are freed; the first one works fine, but the second one doesn't have  
any way of knowing that the object has already been freed.

We ran into this situation in Gtk2-Perl, as well, and that's what the  
set_threadsafe() and object-tracking stuff is all about.  When you  
turn on threadsafety at runtime, the bindings will keep a hash of all  
GObjects that are wrapped by perl scalars, so that when CLONE() is  
invoked for a thread, we can run through all of those wrappers and  
add a reference to their underlying GObjects.  It's a dirty solution,  
but since CLONE() gets invoked by package instead of by object, it's  
all we can do.  It's also the reason my stock advice for threads+gtk2- 
perl problems is either "find some solution that doesn't involve  
threads" or "make sure you create your threads *before* you create  
any widgets".

You may want to forward this thread on to VMware support or whoever  
is responsible for that module.

--
muppet <scott at asofyet dot org>