|
Hi Kjell, I've taken a very quick look
into the first stage that you described (delete some_adjuster):-
On 28/11/2013 09:54, Kjell Ahlstedt wrote:
Hmmm... I do end up with g_object_steal_data() and g_object_set_data() getting called but the path is somewhat different to the one you described. In fact, Gtk::Object::~Object() hasn't even been reached by the time those functions get called. Here's the sequence that I see... 1) Adjustment::~Adjustment() 2) Object::destroy_() 3) Object::_destroy_c_instance() 4) g_object_unref() (which essentially does nothing) 5) gtk_object_destroy() 6) g_object_run_dispose() 7) gtk_object_dispose() 8) g_object_real_dispose() (which does something to do with quarks) 9) Object::disconnect_cpp_wrapper() (which calls those 'steal_data()' and 'set_data()' functions) 9a) The above call also sets 'gobject_' to NULL but does not free up any memory associated with it. 10) Object::~Object() 11) Object::_destroy_c_instance() (gets called a second time but does nothing now because 'gobject_ == 0' But the conclusion of your statement is essentially correct. This convoluted sequence ensures that Glib::ObjectBase::destroy_notify_callback_() does not get called when deleting 'some_adjuster'. And consequently the line "delete this;" (in 'ObjectBase::destroy_notify_()') doesn't get reached either. Nevertheless, 'some_adjuster' does get deleted of course (the CRT deletes it). Tomorrow I'll look into what's happening when we delete the Gtk::SpinButton. For example, is it assuming that the above actions somehow prevented the Gtk::Adjustment from getting deleted? John |