On 07/06/2019 13:26, Daniel Boles via
gtkmm-list wrote:
>>>
Now, using the TreeModel and passing
iterators, I get a shed load of
Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path:
assertion
'iter->user_data != NULL' failed
interspersed with my own debug report of invalid iters
passed to
on_combo_changed()
I don't think this is connected with the coupling. If I
comment out the
forward coupling call it makes little difference. I've also
tried
calling unset_active() before the clear() but it didn't
help.
>>>
Yep:
```
G_DEBUG=fatal-criticals
gdb ./your_exe
run
bt
```
That gives me:
Thread 1 "vpctrl" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff5c87745 in _g_log_abort () from
/usr/lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff5c87745 in _g_log_abort () from
/usr/lib64/libglib-2.0.so.0
#1 0x00007ffff5c88a51 in g_logv () from /usr/lib64/libglib-2.0.so.0
#2 0x00007ffff5c88c2f in g_log () from /usr/lib64/libglib-2.0.so.0
#3 0x00007ffff732ac04 in gtk_tree_store_get_path () from
/usr/lib64/libgtk-x11-2.0.so.0
#4 0x00007ffff7a8cfb6 in
Gtk::TreeModel_Class::get_path_vfunc_callback(_GtkTreeModel*,
_GtkTreeIter*) () from /usr/lib64/libgtkmm-2.4.so.1
#5 0x00007ffff71bf7fa in gtk_combo_box_set_active_iter () from
/usr/lib64/libgtk-x11-2.0.so.0
#6 0x000055555562c6e2 in TRateControlDlg::SetMaterialComboIter
(this=0x5555559fcf30, iter=...)
at AutoControl.h:60
#7 0x000055555562c231 in TAppWindow::SetMaterialIter
(this=0x7fffffffd880, iter=...)
at MainView.cc:993
#8 0x0000555555678041 in MaterialSelector::on_combo_changed
(this=0x55555597b628)
at DepositionView.cc:570
#9 0x000055555567f8f2 in sigc::bound_mem_functor0<void,
MaterialSelector>::operator() (
this=0x5555559f4478) at
/usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#10 0x000055555567f4ee in
sigc::adaptor_functor<sigc::bound_mem_functor0<void,
MaterialSelector> >::operator() (this=0x5555559f4470) at
/usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#11 0x000055555567ef40 in
sigc::internal::slot_call0<sigc::bound_mem_functor0<void,
MaterialSelector>, void>::call_it (rep=0x5555559f4440) at
/usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#12 0x00007ffff66b61a8 in
Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) ()
from /usr/lib64/libglibmm-2.4.so.1
#13 0x00007ffff5d63b6d in g_closure_invoke () from
/usr/lib64/libgobject-2.0.so.0
#14 0x00007ffff5d763e3 in signal_emit_unlocked_R () from
/usr/lib64/libgobject-2.0.so.0
#15 0x00007ffff5d7f802 in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#16 0x00007ffff5d7fe6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#17 0x00007ffff71b9c81 in gtk_combo_box_set_active_internal () from
/usr/lib64/libgtk-x11-2.0.so.0
#18 0x0000555555678a4c in MaterialSelector::Populate
(this=0x55555597b628)
at DepositionView.cc:676
#19 0x000055555567b938 in TDepositionView::Populate
(this=0x55555597b470) at DepositionView.cc:883
and thence into bits of my code.
With the coupling commented out, the backtrace is:
Thread 1 "vpctrl" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff5c87745 in _g_log_abort () from
/usr/lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff5c87745 in _g_log_abort () from
/usr/lib64/libglib-2.0.so.0
#1 0x00007ffff5c88a51 in g_logv () from
/usr/lib64/libglib-2.0.so.0
#2 0x00007ffff5c88c2f in g_log () from
/usr/lib64/libglib-2.0.so.0
#3 0x00007ffff732ac04 in gtk_tree_store_get_path () from
/usr/lib64/libgtk-x11-2.0.so.0
#4 0x00007ffff7a8cfb6 in
Gtk::TreeModel_Class::get_path_vfunc_callback(_GtkTreeModel*,
_GtkTreeIter*) () from /usr/lib64/libgtkmm-2.4.so.1
#5 0x00007ffff71bf7fa in gtk_combo_box_set_active_iter () from
/usr/lib64/libgtk-x11-2.0.so.0
#6 0x00005555556419e5 in MaterialSelector::set_active
(this=0x555555950a28, iter=...)
at DepositionView.h:48
#7 0x0000555555641a38 in TDepositionView::SetMaterialComboIter
(this=0x555555950870, idx=...)
at DepositionView.h:128
#8 0x000055555563b221 in TRateControlDlg::MaterialClick
(this=0x55555581ae00)
at AutoControl.cc:231
#9 0x00005555556432f0 in sigc::bound_mem_functor0<void,
TRateControlDlg>::operator() (
this=0x555555b059a8) at
/usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#10 0x0000555555642df6 in
sigc::adaptor_functor<sigc::bound_mem_functor0<void,
TRateControlDlg> >::operator() (this=0x555555b059a0) at
/usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#11 0x00005555556427d8 in
sigc::internal::slot_call0<sigc::bound_mem_functor0<void,
TRateControlDlg>, void>::call_it (rep=0x555555b05970) at
/usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#12 0x00007ffff66b61a8 in
Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) ()
from /usr/lib64/libglibmm-2.4.so.1
#13 0x00007ffff5d63b6d in g_closure_invoke () from
/usr/lib64/libgobject-2.0.so.0
#14 0x00007ffff5d763e3 in signal_emit_unlocked_R () from
/usr/lib64/libgobject-2.0.so.0
#15 0x00007ffff5d7f802 in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#16 0x00007ffff5d7fe6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#17 0x00007ffff71bcf76 in gtk_combo_box_model_row_deleted () from
/usr/lib64/libgtk-x11-2.0.so.0
#18 0x00007ffff5d63b6d in g_closure_invoke () from
/usr/lib64/libgobject-2.0.so.0
#19 0x00007ffff5d768f3 in signal_emit_unlocked_R () from
/usr/lib64/libgobject-2.0.so.0
#20 0x00007ffff5d7f802 in g_signal_emit_valist () from
/usr/lib64/libgobject-2.0.so.0
#21 0x00007ffff5d7fe6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#22 0x00007ffff732d100 in gtk_tree_store_remove () from
/usr/lib64/libgtk-x11-2.0.so.0
#23 0x00007ffff732d295 in gtk_tree_store_clear_traverse () from
/usr/lib64/libgtk-x11-2.0.so.0
#24 0x00007ffff732d245 in gtk_tree_store_clear_traverse () from
/usr/lib64/libgtk-x11-2.0.so.0
#25 0x00007ffff732d245 in gtk_tree_store_clear_traverse () from
/usr/lib64/libgtk-x11-2.0.so.0
#26 0x00007ffff732e606 in gtk_tree_store_clear () from
/usr/lib64/libgtk-x11-2.0.so.0
#27 0x0000555555678a6d in MaterialSelector::Populate
(this=0x555555950a28)
at DepositionView.cc:677
#28 0x000055555567b93c in TDepositionView::Populate
(this=0x555555950870) at DepositionView.cc:883
Which means it actually gets a bit further before the first
critical. However, entry #8 of that second backtrace is invoking
the signal_changed handler of the second combobox, which then
passes that to the primary at #5, moving that away from its
"unset" state.
Is it going to be enough to "unset_active" the second combobox
before clear()-ing the TreeStore? Or do I need to do something
more complex? (I think the code needs re-structuring to reduce the
levels of nesting needed for even that simple option, but that's a
separate matter)
Thanks,
Rob
