On 09/11/2013 15:05, John Emmas wrote:
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 |