After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575696 - extreme slowness in GtkTreeView on row selection/insertion
extreme slowness in GtkTreeView on row selection/insertion
Status: RESOLVED DUPLICATE of bug 577098
Product: gtk+
Classification: Platform
Component: Accessibility
2.12.x
Other All
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-17 13:53 UTC by john.roden
Modified: 2011-01-20 10:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description john.roden 2009-03-17 13:53:27 UTC
Please describe the problem:
I am building a browser/editor to view/modify an ontology represented as a network of nodes and edges (about 150,000 nodes). The network is displayed 
as a set of trees, using the GtkTreeView (via gtkmm toolkit). A custom tree model is used to convert the network into a strict tree view.

Certain operations (selection of a row,  pasting new rows) can cause a very
large number of calls to the tree model from GtkTreeView causing the application to pause unacceptably or sometimes hang in an endless loop.
The problem is reproducible.

By chance I discovered that setting the GTK_MODULES env variable to blank
removed the problem completely.  It was set to "gnomebreakpad:gail:atk-bridge".

This strengthens a suspicion that the problem is related to libgail.so.  When
the program is interrupted during the looping, the backtrace from GDB always
shows libgail.so in the trace.  An example trace is included below.

If the target row for a paste operation has children and is expanded, the 
looping occurs;  if it is not expanded, no looping happens.  The looping
always involved calls to the tree model for nodes which are not displayed
and each node is visited repeatedly (5 times and more). I have discounted
the possibility of circular linking between the nodes and in any case the
number on non-visible nodes being visited is unnecessary and does not
happen in other operations.

I have not investigated the problem in more depth and cannot tell if this
should be reported under gail or GtkTreeView.  Also I have not had time
to create a small example but I can supply the whole application if required.


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
yes

Other information:
(gdb) bt
#0  std::_Rb_tree<memory_store::node_record*, std::pair<memory_store::node_record* const, memory_store::edge_record*>, std::_Select1st<std::pair<memory_store::node_record* const, memory_store::edge_record*> >, std::less<memory_store::node_record*>, std::allocator<std::pair<memory_store::node_record* const, memory_store::edge_record*> > >::_S_key (__x=0xa227428) at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_tree.h:475
  • #1 std::_Rb_tree<memory_store::node_record*, std::pair<memory_store::node_record* const, memory_store::edge_record*>, std::_Select1st<std::pair<memory_store::node_record* const, memory_store::edge_record*> >, std::less<memory_store::node_record*>, std::allocator<std::pair<memory_store::node_record* const, memory_store::edge_record*> > >::_M_upper_bound
    at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_tree.h line 989
  • #2 std::_Rb_tree<memory_store::node_record*, std::pair<memory_store::node_record* const, memory_store::edge_record*>, std::_Select1st<std::pair<memory_store::node_record* const, memory_store::edge_record*> >, std::less<memory_store::node_record*>, std::allocator<std::pair<memory_store::node_record* const, memory_store::edge_record*> > >::upper_bound
    at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_tree.h line 724
  • #3 std::multimap<memory_store::node_record*, memory_store::edge_record*, std::less<memory_store::node_record*>, std::allocator<std::pair<memory_store::node_record* const, memory_store::edge_record*> > >::upper_bound
    at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_multimap.h line 615
  • #4 memory_store::get_edges_all
    at ../Source/storage_2mysql.cpp line 1380
  • #5 Ontology::Storage_2MySQL::read_node_edges
    at ../Source/storage_2mysql.cpp line 2044
  • #6 Ontology::Term::links
    at ../Source/term.cpp line 361
  • #7 Ontology_TreeModel::term_node::n_children
    at ../Source/ontology_treemodel.cpp line 262
  • #8 Ontology_TreeModel::iter_has_child_vfunc
    at ../Source/ontology_treemodel.cpp line 620
  • #9 Gtk::TreeModel_Class::iter_has_child_vfunc_callback
    from /usr/lib/libgtkmm-2.4.so.1
  • #10 gtk_tree_model_iter_has_child
    from /usr/lib/libgtk-x11-2.0.so.0
  • #11 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #12 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #13 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #14 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #15 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #16 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #17 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #18 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #19 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #20 atk_object_ref_accessible_child
    from /usr/lib/libatk-1.0.so.0
  • #21 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #22 atk_object_ref_accessible_child
    from /usr/lib/libatk-1.0.so.0
  • #23 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #24 atk_object_ref_accessible_child
    from /usr/lib/libatk-1.0.so.0
  • #25 ??
    from /usr/lib/gtk-2.0/modules/libatk-bridge.so
  • #26 ??
    from /lib/libgobject-2.0.so.0
  • #27 g_signal_emit_valist
    from /lib/libgobject-2.0.so.0
  • #28 g_signal_emit_by_name
    from /lib/libgobject-2.0.so.0
  • #29 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #30 ??
    from /usr/lib/libgtk-x11-2.0.so.0
  • #31 ??
  • #32 ??
  • #33 ??
  • #34 ??
  • #35 ??
    from /usr/lib/gtk-2.0/modules/libgail.so
  • #36 ??
  • #37 ??
  • #38 ??
  • #39 g_datalist_clear
    from /lib/libgobject-2.0.so.0
  • #40 ??
  • #41 ??
  • #42 g_closure_invoke
    from /lib/libgobject-2.0.so.0

Comment 1 Kristian Rietveld 2009-09-06 12:31:22 UTC
I agree with you that this is a gail problem.  Moving.
Comment 2 Li Yuan 2011-01-20 10:47:24 UTC

*** This bug has been marked as a duplicate of bug 577098 ***