----- Original Message ----
From: larcky pclar7@yahoo.co.uk To: pike@roxen.com Sent: Thu, September 22, 2011 3:17:33 AM Subject: Possible bug walking a GTK2.TreeModel in 7.9
Hi This works fine in Pike 7.8 but 7.9 crashes with a Segmentation Fault. I think the problem's with GTK2.TreeModel->iter_next(). I can get the first row OK but then the iterator becomes invalid. Thanks, larcky
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.
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.
pike-devel@lists.lysator.liu.se