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
|
