Re: Is gtkmm deleting stuff it shouldn't be deleting ??

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

2013-11-08 09:12, John Emmas skrev:

On 07/11/2013 17:39, John Emmas wrote:

On 07/11/2013 16:08, Kjell Ahlstedt wrote:

I've used gdb to see what's happening in the functions that you mention. The datalist in g_datalist_get_data() contains 2 entries:

-- GQuark 1007, "gtk-window-icon-info"
-- GQuark 181, "glibmm_Glib::quark_cpp_wrapper_deleted_"

You're right.  In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d->len) equals 3 and their values are:-

1st entry:  93    // Don't know how to work
2nd entry: 856   // out what these ones are
3rd entry: 3219138047   // I'm assuming this one's garbage.

The above values are the values I get when the search string is "gtk-selection-handlers".  For other search strings I get different values.

Hi Kjell,

Better late than never but this morning, I realised I could simply print out the relevant strings!  Here's what I'm getting for those first two entries:-

      1st entry (GQuark 93)    = "glibmm__Glib::quark_"
      2nd entry (GQuark 856)  = "gtk-window-icon-info"

Notice that my 2nd string is the same as your 1st string.  I wonder if this indicates some kind of alignment problem?

John

There are two errors in your datalist, I think.
First of course the third garbage entry.
Second glibmm_Glib::quark_ instead of glibmm_Glib::quark_cpp_wrapper_deleted_.

Here's a backtrace from gdb when gtk_widget_unrealize() is called, with some missing functions manually added.

#0  g_quark_to_string (quark=1007) at gquark.c:260
#1  0x00007ffff4f84648 in g_datalist_get_data (datalist=datalist entry=0x6bf0e0,
    key=key entry=0x7ffff5ad8c30 <gtk_selection_handler_key> "gtk-selection-handlers")
    at gdataset.c:1036
#2  0x00007ffff529a83f in g_object_get_data (object=object entry=0x6bf0d0,
    key=key entry=0x7ffff5ad8c30 <gtk_selection_handler_key> "gtk-selection-handlers")
    at gobject.c:3444
#3  0x00007ffff590f5f8 in gtk_selection_target_list_remove (widget=0x6bf0d0) at gtkselection.c:817
#4  IA__gtk_selection_remove_all (widget=widget entry=0x6bf0d0) at gtkselection.c:999
#5  0x00007ffff59bfa5f in gtk_widget_real_unrealize (widget=0x6bf0d0) at gtkwidget.c:8950
#6  0x00007ffff5291007 in _g_closure_invoke_va (closure=0x6a98c0, return_value=0x0,
    instance=0x6bf0d0, args=0x7fffffffd758, n_params=0, param_types=0x0) at gclosure.c:840
#7  0x00007ffff52aae5c in g_signal_emit_valist (instance=0x6bf0d0, signal_id=<optimized out>,
    detail=<optimized out>, var_args=var_args entry=0x7fffffffd758) at gsignal.c:3238
#8  0x00007ffff52ab732 in g_signal_emit (instance=instance entry=0x6bf0d0,
    signal_id=<optimized out>, detail=detail entry=0) at gsignal.c:3386
#9  0x00007ffff59c3592 in IA__gtk_widget_unrealize (widget=0x6bf0d0) at gtkwidget.c:3605
#10 0x00007ffff59c4a20 in gtk_widget_dispose (object=0x6bf0d0) at gtkwidget.c:8791
#11 0x00007ffff5297730 in g_object_run_dispose (object=0x6bf0d0) at gobject.c:1077
  Missing from gdb's backtrace:
    gtk_object_destroy()                gtkobject.c:402
    Gtk::Window::_destroy_c_instance()  window.cc:111
    Gtk::Window::destroy_()             window.cc:97
#12 0x00007ffff7aa1dcf in Gtk::Window::~Window (this=0x6a5ff0, __in_chrg=<optimized out>,
    __vtt_parm=<optimized out>) at window.cc:612
#13 0x00007ffff7aa1ea9 in Gtk::Window::~Window (this=0x6a5ff0, __in_chrg=<optimized out>,
    __vtt_parm=<optimized out>) at window.cc:613
#14 0x0000000000400b60 in main (argc=1, argv=0x7fffffffd9b8) at main3.cc:13

Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(), it calls Gtk::Object::disconnect_cpp_wrapper(), which removes glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_.

I have run your test case that contains delete mainWnd.

Which versions of glib, glibmm, gtk+, and gtkmm do you use?

Kjell