GNOME Bugzilla – Bug 722781
Foreach call on sort model fails with sort function
Last modified: 2014-12-09 05:43:01 UTC
Created attachment 266985 [details] tree_store.c If one sets a sort function on a sort model, and then tries to call gtk_tree_model_foreach() on it, it will generate warnings, as the tree iters change during foreach()'s run. Test case attached, simply click on the "Select all" button for the sort model window. See also that the recent func is empty. The sort model itself is the one generating tree iter for its sort function, and changing the stamps, invalidating them for the foreach function. $ ./tree_store (tree_store:944): Gtk-CRITICAL **: gtk_tree_model_sort_iter_children: assertion 'VALID_ITER (parent, tree_model_sort)' failed (tree_store:944): Gtk-CRITICAL **: gtk_tree_model_sort_iter_next: assertion 'priv->stamp == iter->stamp' failed
Not using a sort_func (remove the call to gtk_tree_sortable_set_sort_func()) results in the exact same behaviour. So it's impossible to work around this problem without losing the sorting.
Well, but this expected/normal behavior, though. I mean while nothing is mentioned on gtk_tree_model_foreach() itself, this is how things work (from GtkTreeModel): " The lifecycle of an iterator can be a little confusing at first. Iterators are expected to always be valid for as long as the model is unchanged (and doesn't emit a signal). (...) Additionally, some models guarantee that an iterator is valid for as long as the node it refers to is valid (most notably the GtkTreeStore and GtkListStore). (...) As a result, the GTK_TREE_MODEL_ITERS_PERSIST flag was added to indicate this behavior. " Indeed, both sort model & filter model do not have this flag, and therefore all of their iters are expected to be invalid as soon as the model is changed, and you do change it(*) in your set_selection_foreach() (*) I mean you do work on the actual/child model, but that's how those "proxy" models work, you should only ever change the child model, and changing it does invalidate all iters on the "proxy" model. It can make things a bit painful when dealing with those models, but it's not actually a bug. (And the fact that things appear to work with filter model is just luck, not a guarantee. That is only so for list & tree store.)
(In reply to comment #2) > Well, but this expected/normal behavior, though. I know, which means it's unusable. So something will have to give.