Re: compiling gtkmm with atkmm support fails in implementor.cc

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

Den 2015-11-18 kl. 13:39, skrev John Emmas:

On 18/11/2015 08:05, Kjell Ahlstedt wrote:

Only Gtk::Window contains the Glib::RefPtr<Gtk::AccelGroup> accel_group_ which also seems to be involved in a way that I don't understand.

I must admit, I'm also baffled by this.  In my simple example, the order of destruction seems to be this:-

        ~Widget
        ~Container
        ~Bin
        ~Window
        ~Implementor

That's not right. The expected order of creation of a Gtk::Window is

sigc::trackable (only pointer member data)
Glib::ObjectBase (pointer and bool member data)
Glib::Object (no member data)
Gtk::Object (only bool member data)

Glib::Interface (no member data)
Gtk::Buildable (no member data)

Glib::Interface (no member data)
Atk::Implementor (no member data)

Gtk::Widget (no member data)
Gtk::Container (no member data)
Gtk::Bin (no member data)
Gtk::Window's member data (Glib::RefPtr<Gtk::AccelGroup> accel_group_)
Gtk::Window

Destruction is expected to be done in the opposite order:

~Window
~RefPtr<AccelGroup>
~Bin
~Container
~Widget
~Implementor
and so on

That's what I get with gcc.

And the crash / hang always happens while destroying Implementor.  I did notice this comment at line 53 of 'glibmm/glib/glibmm/interface.cc':-

   //Any instantiable class that derives from Interface should also inherit from Object.

I noticed that Atk::Implmentor does derive from Glib::Interface but it doesn't inherit from Object.  Could that be the problem?

No, it's no problem. Atk::Implementor is not an instantiable class. Gtk::Widget is an instantiable class. It inherits from Gtk::Object, Gtk::Buildable and Atk::Implementor.

I tested your program that consists of

  Atk::Implementor* imp = new Atk::Implementor (NULL);
  delete imp;  // <-- hangs here !!

It did not hang or crash. Like you suspect, it's not valid code. Atk::Implementor is an interface. It shall not be instantiated except as a base class of an object. Still it's interesting that it hangs with MSVC, but not with gcc. Can you see what's happening when it hangs? Is it an infinite loop? Does it wait for some signal from somewhere? Is it a problem with the communication with the atkmm dll (assuming that atkmm is in a separate dll)?

Kjell