On 11.11.2013 01:09, Kevin Ryde wrote:
How has this bit gone? It definitely seems to do something unexpectedly bad. How would you feel about reverting until the reason can be found?
I've had another look at this and now think that I understand what is going on: Your MyContainer class derives from Gtk2::HBox and so, by extension, from Glib::InitiallyUnowned. The GObject underlying the instance created by libgobject thus has only a single, floating reference. When marshalling this object for INIT_INSTANCE, another reference is added, but the existing reference is kept in the floating state (due to own=FALSE in the gperl_new_object() call in gperl_type_instance_init()). Without the call to $label->parent, this additional reference is simply removed when INIT_INSTANCE exits (with the change under discussion) or sometime later (without it), and the original floating reference remains. It later gets sunk in the marshalling of the MyContainer->new call. If you do, however, call $label->parent, then the marshalling code sees that the underlying GObject has a floating reference and takes over ownership of it (without adding a new reference). The GObject now has two references to it, one from $self and one from $parent. With the change under discussion, both of these get removed when INIT_INSTANCE exits, leading to the destruction of the GObject. Without the change, the removal of the reference from $self to the GObject is delayed until after the MyContainer->new call returned and $mycontainer added another reference, thus preventing the destruction of the GObject. So at this point, reverting the change (as in the attached patch) does seem like a sensible thing to do. This comes with a cost, however; for example, Glib::Object::Introspection's test suite breaks. So I have to ask: why are you calling $label->parent in INIT_INSTANCE instead of simply using $self?
Attachment:
0001-WIP.patch
Description: Text Data