2013-11-29 18:13, John Emmas skrev:
On 29/11/2013 16:29, Kjell Ahlstedt wrote:
It would be fine if you could try to find out what goes wrong when
g_object_steal_qdata() is called. Why isn't the GQuark removed from
the list of the GtkAdjustment's quarks?
Yes you're onto something Kjell. The call to 'steal_qdata' looks like
this:-
g_object_steal_qdata((GObject*)gobj(), Glib::quark_);
The value of 'Glib::quark_' is ludicrously high (3232507391) which
looks like an uninitialized number to me. Also, when we step to the
next line:-
g_object_set_qdata((GObject*)gobj(),
Glib::quark_cpp_wrapper_deleted_, (gpointer)true);
The value of 'Glib::quark_cpp_wrapper_deleted_' is also ludicrously
high. These quark values are either uninitialized or there's some
kind of signed / unsigned mismatch somewhere.
In function main() I call:-
Gtk::Main app(&argc, &argv);
The above line calls 'gtk_init()' but is something extra needed for
initializing glibmm? I'm sure I once tried this with plain GTK+ and
the values were reasonable.
John
Glib::quark_ and Glib::quark_cpp_wrapper_deleted_ are statically
allocated data, initialized to 0 in glibmm/glib/glibmm/quark.cc. They
get their real values in glibmm/glib/glibmm/wrap.cc,
Glib::wrap_register_init().
Glib::quark_ probably has a reasonable value in
Glib::ObjectBase::_set_current_wrapper(), when g_object_set_qdata_full()
is called.
Is it possible that you have some inconsistency between glibmm and
gtkmm? That Glib::quark_ has a reasonable value when it's accessed in a
glibmm function, but not when it's accessed in a gtkmm function? Can you
see if Glib::quark_'s address is the same in
Glib::ObjectBase::_set_current_wrapper() as in
Gtk::Object::disconnect_cpp_wrapper()?
Kjell
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list