GNOME Bugzilla – Bug 124662
tree model keeps a node around with a zero refcount until its parent frees it
Last modified: 2018-07-01 08:40:28 UTC
Running gconf-editor, do the following: - Right-click on the right-side pane and select 'New Key' to add a new key. - The new key dialog appears, Key path is '/'. - Type "part1/part2" for the Key name. - Type "123" for the Key value. - Click OK button to create the new key. - Refresh the keypath tree on the left-side pane by collapsing and expanding it. - Select the key node "part2", right-click to delete it. - Refresh the keypath tree on the left-side pane by collapsing and expanding it. gconf-editor segmentation faults at this point. Below is the stack trace: 0x08059d55 in gconf_tree_model_ref_node (tree_model=0x80b5808, iter=0xbffff170) at gconf-tree-model.c:419 419 node->ref_count += 1; (gdb) where
+ Trace 40875
*** Bug 123950 has been marked as a duplicate of this bug. ***
Fixed on HEAD by Sanjiv. We should backport this to gnome-2-4. Is it okey to commit to 2-4 and close?
Sure, go ahead. Fernando, if you want you can release a new version for 2.4 as well. I think Kjartan is working on 2.4.2, ccing him.
Fernando: given that this only has one dup, TARGET2.6.0 was probably not appropriate. Anyway, since it is fixed in HEAD, removing the keyword and setting GNOMEVER2.4. Fernando, Muktha, if either of you has a patch you'd like for the backport, please attach and reopen, but I believe Kjartan has said that 2.4.2 was the last 2.4 release.
Sanjiv's patch is incorrect, I'm afraid. It goes: +++ gconf-tree-model.c 3 Feb 2004 06:32:22 -0000 1.16 @@ -458,7 +458,7 @@ if (node->ref_count == 0) { if ((node->parent != NULL) && (node->parent->children == node)) - node->parent->children = node->next; + node->parent->children = node->children; You can't just "move up" the children of node! This will also leak the old siblings of node. You may want to look at gtk+/gtk/gtkfilesystemmodel.c as a reference for how to implement ref_node and unref_node.
Created attachment 26136 [details] [review] Proposed fix Federico, can you take a look at this? Thanks
The call to clear_node in unref() should be free_node instead. Otherwise you'll be keeping a node around with a zero refcount until its parent frees it.
Humm doing that makes gtk_tree_view entering in an infite loop with gtk_cell_renderer_render
Patch applied, bescause it's better to fix the two crashing bugs and remain a little semi-leak. Should investigate more this.
Changing to _clear_node there gives me backtraces with memory corruption before gconf-editor even starts up.
gconf-editor is not under active development anymore and has not seen code changes for six years. Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf-editor/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.