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
|
