On Mon, 2013-11-04 at 17:58 +0000, John Emmas wrote:
> Allowing the window to close normally will call
> 'gtk_widget_destroy()'
I wouldn't expect that. gtkmm Windows are not destroyed just because you
close them, though that can be the case with regular GTK+ windows.
> which, in turn, calls 'gtk_object_destroy()' and
> ultimately, 'g_object_run_dispose()'. As expected, the gtkmm window
> disappears from my screen.
And you think that the GObject and/or the C++ instance is freed here,
right? But how are you sure of that?
On Linux, valgrind would tell us about use of freed memory.
> Now we reach this line:-
>
> delete mainWnd; // <--- crashes here !
>
> The above line invokes the d'tor for Gtk::Window. The d'tor calls
> 'Gtk::Window::destroy_()' which then calls
> 'Gtk::Window::_destroy_c_instance()'. Note that
> 'Gtk::Window::_destroy_c_instance()' contains some warnings about
> ensuring that 'C' and C++ objects get destroyed in the correct
> sequence. Once inside 'Gtk::Window::_destroy_c_instance()' we hit
> this
> code:-
>
> if (!gobject_disposed_)
> {
> //Windows can not be unrefed. They are "self-owning".
> gtk_object_destroy(object);
> }
>
> and bingo! We call 'gtk_object_destroy()' all over again on an
> object
> that's already been destroyed! The crash actually occurs in
> 'g_object_run_dispose()' at this line:-
>
> G_OBJECT_GET_CLASS (object)->dispose (object);
>
> Effectively, we're trying to get the class of an object that GTK+
> just
> destroyed for us. Hope you can make sense of all that!
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
