I believe I see the problem. In 7.9, in gtktreemodel.pre, function iter_next,
it was changed to push the iter onto the stack, to return it. This way you can
possibly do things like iter2=tm->iter_next(iter). The problem is that iter gets modified in place by gtk_tree_model_iter_next(), so it is there, then it
gets pushed onto the stack also. So the same GtkTreeIter is present twice, once
in the original object, and another on the stack. When the one on the stack doesn't get assigned to anything, it gets free'd by gtk, so the original iter
gets free'd also. Then when you try to use it again, possibly the memory is fine and hasn't been overwritten yet, but when it tries to free it again, it gets the double free. 7.9 needs to be changed to either copy the iter, or to
not return it.
Does anybody have a preference? I don't think the copy would be the right thing
to do, because it would usually consist of a copy and a free anyway, because you
won't probably won't use the old one once you have the next one.
I don't think there is any way to do it otherwise because gtk_tree_model_iter_next() replaces the iter, it doesn't return the next one as
a new iter, leaving the old one alone.
Okay I removed the second push of the GtkTreeIter, and changed it to only return the status of the call (true if iter was set). This partially reverts commit f439a10a801922cf6cf628352c5b1322cb4aae97.
I just verified that this fixed the problem.