> > 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.
