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 722781 - Foreach call on sort model fails with sort function
Foreach call on sort model fails with sort function
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
3.10.x
Other Mac OS
: Normal major
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2014-01-22 17:00 UTC by Bastien Nocera
Modified: 2014-12-09 05:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tree_store.c (16.61 KB, text/plain)
2014-01-22 17:00 UTC, Bastien Nocera
Details

Description Bastien Nocera 2014-01-22 17:00:54 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
Comment 1 Bastien Nocera 2014-01-22 17:13:51 UTC
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.
Comment 2 Olivier Brunel (jjacky) 2014-01-22 18:07:34 UTC
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.)
Comment 3 Bastien Nocera 2014-01-22 18:15:47 UTC
(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.