On 09/11/2013 15:05, John Emmas wrote:
On 08/11/2013 14:16, Kjell Ahlstedt wrote:

Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(), it calls Gtk::Object::disconnect_cpp_wrapper(), which removes glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_.


Thanks Kjell, I'll test that on my system and see if I also get those changes (I'm guessing I won't).


Hi Kjell, I got so bogged down with gtkmm problems that I forgot about comparing my own execution path here - but yes, my code follows the very same path. FWIW this is the interesting code from 'gtk/gtkmm/object.cc' (function 'Object::disconnect_cpp_wrapper()')

    if(gobj())
    {
//Prevent gtk vfuncs and default signal handlers from calling our instance methods: g_object_steal_qdata((GObject*)gobj(), Glib::quark_); //It will no longer be possible to get the C++ instance from the C instance.

//Allow us to prevent generation of a new C++ wrapper during destruction: g_object_set_qdata((GObject*)gobj(), Glib::quark_cpp_wrapper_deleted_, (gpointer)true);

      //Prevent C++ instance from using GTK+ object:
      gobject_ = 0;
    }

Pay particular attention to that last comment. This, I believe, is the root of the problem. Setting 'gobject_' to zero DOES NOT prevent any C++ wrapper from attempting to access it. Here's an example from Gtk::Widget::on_unrealize() which can get called AFTER the call to Object::disconnect_cpp_wrapper().

    void Gtk::Widget::on_unrealize()
    {
      BaseClassType *const base = static_cast<BaseClassType*>(
g_type_class_peek_parent(G_OBJECT_GET_CLASS(gobject_)) // Get the parent class of the object class (The original underlying C class).
      );

      if(base && base->unrealize)
        (*base->unrealize)(gobj());
    }

The commented line consistently crashes (for me) if 'gobject_' is zero. I gave a very similar example here yesterday:-

https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00034.html

The consensus of replies was that it's NOT safe to call these functions if gObject_ == NULL. Does that give us any more help in tracking these issues down??

John
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to