Re: Gtk::SpinButton crash

[John Emmas <johne53 tiscali co uk>]

Hi Kjell - we're back here again...  :-(

On 22/11/2013 15:58, Kjell Ahlstedt wrote:

What's going on in your system? I get a feeling that the patches you've applied to your copy of gtkmm 2.24.4 only hide the symptoms of a different bug than the one those patches fixed in gtkmm 3.

I must admit that's niggling away at me too - but let's worry about that if we find some actual evidence...

Did you test with or without the patches from bug 605728?

Right at this minute I'm testing with the patches applied.  However, I'd already observed this problem before applying the patches (it was #2 on a list of two gtkmm issues I keep seeing).  In other words, the patches haven't introduced the problem.  It was already there.

Does the order of definition of some_spin_button and some_adjuster matter? When some_spin_button is defined before some_adjuster, some_adjuster will be deleted before some_spin_button (at least the C++ part of it, probably not the underlying GtkAdjustment).

You're definitely onto something there....

This crashes:-

        Gtk::SpinButton some_spin_button;
        Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
        some_spin_button.set_adjustment (some_adjuster);

This doesn't:-

        Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
        Gtk::SpinButton some_spin_button;
        some_spin_button.set_adjustment (some_adjuster);

This crashes:-

        Gtk::SpinButton* some_spin_button = new Gtk::SpinButton;
        Gtk::Adjustment* some_adjuster = new Gtk::Adjustment (2, 0, 100, 1, 10, 0);
        some_spin_button->set_adjustment (*some_adjuster);

        delete some_adjuster;
        delete some_spin_button;

This doesn't:-

        Gtk::SpinButton* some_spin_button = new Gtk::SpinButton;
        Gtk::Adjustment* some_adjuster = new Gtk::Adjustment (2, 0, 100, 1, 10, 0);
        some_spin_button->set_adjustment (*some_adjuster);

        delete some_spin_button;
        delete some_adjuster;

So it seems to be an issue if the adjuster gets destroyed before the spin button.  FWIW the crash occurs in ObjectBase::destroy_notify_callback_() at the call to 'cppObject->destroy_notify_()'

      void ObjectBase::destroy_notify_callback_(void* data)
      {
        //GLIBMM_LIFECYCLE

        // This method is called (indirectly) from g_object_run_dispose().
        // Get the C++ instance associated with the C instance:
        ObjectBase* cppObject = static_cast<ObjectBase*>(data); //Previously set with g_object_set_qdata_full().

      #ifdef GLIBMM_DEBUG_REFCOUNTING
        g_warning("ObjectBase::destroy_notify_callback_: cppObject = %p, gobject_ = %p, gtypename = %s\n",
                  (void*) cppObject, (void*) cppObject->gobject_, G_OBJECT_TYPE_NAME(cppObject->gobject_));
      #endif

        if(cppObject) //This will be 0 if the C++ destructor has already run.
        {
           cppObject->destroy_notify_(); //Virtual - it does different things for GObject and GtkObject.
        }
      }

When the crash does NOT occur 'cppObject' and 'cppObject.gobject_' are both valid and Object::destroy_notify_() gets called.  When the crash occurs, 'cppObject' seems to be valid but 'cppObject.gobject_' is 0xfeeefeee.  That value usually indicates that the CRT has just freed some memory associated with that variable.  A couple of times I noticed the crash happening at the line indicated below - but it wasn't 100% consistent:-

      void ObjectBase::destroy_notify_()
      {
        #ifdef GLIBMM_DEBUG_REFCOUNTING
          g_warning("Glib::ObjectBase::destroy_notify_: gobject_ = %p", (void*) gobject_);
        #endif

          gobject_ = 0; // Make sure we don't unref it again in the dtor.

          delete this;  // <--- crash was observed here
      }

Does any of that help us?

John