GNOME Bugzilla – Bug 722030
[PATCH] Memory leak when scrolling through GtkTreeView
Last modified: 2014-02-21 02:57:01 UTC
Created attachment 266050 [details] [review] Fix memory leak Valgrind reports the following memory leak when scrolling through a GtkTreeView (using the down arrow key): ==3644== 161,308 (73,248 direct, 88,060 indirect) bytes in 654 blocks are definitely lost in loss record 12,759 of 12,759 ==3644== at 0x5A151DA: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.3800.2) ==3644== by 0x59F9604: ??? (in /usr/lib/libgobject-2.0.so.0.3800.2) ==3644== by 0x59FB7B3: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.3800.2) ==3644== by 0x59FBB93: g_object_new (in /usr/lib/libgobject-2.0.so.0.3800.2) ==3644== by 0x66ED61E: gtk_renderer_cell_accessible_new (gtkrenderercellaccessible.c:116) ==3644== by 0x66F53B7: create_cell (gtktreeviewaccessible.c:406) ==3644== by 0x66F6BAD: _gtk_tree_view_accessible_add_state (gtktreeviewaccessible.c:1930) ==3644== by 0x6693409: gtk_tree_view_real_set_cursor (gtktreeview.c:13177) ==3644== by 0x6696526: gtk_tree_view_real_move_cursor (gtktreeview.c:10382) ==3644== by 0x65B14F1: _gtk_marshal_BOOLEAN__ENUM_INT (gtkmarshalers.c:531) ==3644== by 0x59F46A7: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.3800.2) ==3644== by 0x5A05DFA: ??? (in /usr/lib/libgobject-2.0.so.0.3800.2) In the various contexts where create_cell() is called, the returned GtkCellAccessible is not unref'ed, so it looks like the reference count for that object is supposed to be transferred to the GtkTreeViewAccessiblePrivate::cell_infos hash table; but in the current code, the object is ref'ed again before being added to the hash table. Removing the extra g_object_ref() where the hash table insertion takes place (in cell_info_new()) seems to fix the leak, but I'm not entirely sure that this is the correct fix.
I'm using NO_AT_BRIDGE=1, in case that makes any difference.
Reopening since this commit makes gedit to crash
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7276008 in _gtk_cell_accessible_state_changed (cell=0x129ee70, added=GTK_CELL_RENDERER_SELECTED, removed=(unknown: 0)) at gtkcellaccessible.c:404 warning: Source file is more recent than executable. 404 g_return_if_fail (GTK_IS_CELL_ACCESSIBLE (cell)); (gdb) bt
+ Trace 233135
Well, as I said: > ... seems to fix the leak, but I'm not entirely sure that this is > the correct fix. Someone with more experience with the code should figure out the right way to fix this leak. Unfortunately, the code is rather badly written and it's hard to tell how it was originally supposed to work.
I wonder if your problem is simply that finalize is never reached, can you try to add a printf in finalize and see if you get there? From the checks I made the cell_info is kept in the hash table and it should be freed, so I wonder if for some reason your accessible is never unreffed and so the hash table is never destroyed.
I reverted this patch
I can't look into the finalize idea at the moment. Please leave the report open and I will get around to it eventually, maybe come up with another patch. Also, what do I need to do to reproduce the GEdit crash?
To repro the crash: * enable the External tools plugin. * open the external tools manager * choose a tool * open the languages popover * change the kind of language the tool will be used
Comment on attachment 266050 [details] [review] Fix memory leak It seems to me we need the ref here because we unref in cell_info_free(). The problem is elsewhere I think.
*** This bug has been marked as a duplicate of bug 695965 ***
Updated patch on #695965 that does not cause GEdit to crash.