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
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
