Yes, I've compiled with gcc.
I tested with John's minimal test program. I used the gdb debugger and stepped through much of the code that is executed from Gtk::Window::~Window(). There is only one call to Glib::Refptr<>::~Refptr. It destructs the Glib::RefPtr<Gtk::AccelGroup> accel_group_ member data in Gtk::Window. pCppObject is nullptr, and therefore unreference() is not called. That's the expected result. Atk::Implementor::~Implementor() is called afterwards, and doesn't really do anything.
The question now is: Why is pCppObject_->unreference() called in the RefPtr destructor when gtkmm,
atkmm and glibmm are built with MSVC? Who sets pCppObject_ to something != nullptr? Or isn't RefPtr's default constructor executed when the Gtk::Window is created?
Kjell
Den 2015-11-17 kl. 13:47, skrev John Emmas:
On 17/11/2015 11:31, John Emmas wrote:
template <class T_CppObject> inline
RefPtr<T_CppObject>::~RefPtr()
{
if(pCppObject_)
pCppObject_->unreference(); // This could cause pCppObject to be deleted.
// ^ ^ ^ CRASH HAPPENS HERE
}
and the above seems to get called during this 'destroy_()' call in 'gtkmm/gtk/gtkmm/window.cc':-
Window::~Window()
{
destroy_();
}
My guess would be that there is indeed some kind of double deletion happening. I'll spend another hour or so on it and see if I can get any further...
I didn't really get much further - except to realise that the crash doesn't happen in that 'destroy_()' call - it actually happens after the call (when 'Window' goes out of scope). So my gut feeling is that this probably isn't a double deletion. Maybe 'pCppObject_->unreference()' is getting called for an object that's already gone out of scope? Is that even possible..?
John