Description of problem: Valgrind reports a bunch of leaks and other problems in the menu method. I've tried to patch some of them in the attached patch. Please review and give feedback on the patch, since I have no idea what the code is really doing :-) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 102988 [details] patch to clean up some issues
Comment on attachment 102988 [details] patch to clean up some issues Found some spurious changes attaching a new one.
Created attachment 102990 [details] updated patch
Damn. Some days I shouldn't be let near a computer. Attaching the right patch now.
Created attachment 102991 [details] updated updated patch
After applying this patch and running valgrind on the panel I still see this leak: ==19085== 5549 bytes in 942 blocks are definitely lost in loss record 167 of 189 ==19085== at 0x1B902A9C: malloc (vg_replace_malloc.c:131) ==19085== by 0xBA6922: g_malloc (in /usr/lib/libglib-2.0.so.0.400.6) ==19085== by 0xBB52A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6) ==19085== by 0x1C17DB12: ??? (menu-process.c:1354) ==19085== by 0x1C1720C6: ??? (menu-method.c:923) ==19085== by 0x1C172F06: ??? (menu-method.c:1149) ==19085== by 0x2C6A761: gnome_vfs_get_file_info_uri_cancellable (in /usr/lib/libgnomevfs-2.so.0.791.0) ==19085== by 0x2C853C0: gnome_vfs_get_file_info_uri (in /usr/lib/libgnomevfs-2.so.0.791.0) ==19085== by 0x2C85415: gnome_vfs_get_file_info (in /usr/lib/libgnomevfs-2.so.0.791.0) ==19085== by 0x8081669: fr_read_dir (menu-fentry.c:434) ==19085== by 0x808193D: ??? (menu-fentry.c:304) ==19085== by 0x80816AD: fr_read_dir (menu-fentry.c:472) ==19085== by 0x808193D: ??? (menu-fentry.c:304) ==19085== by 0x80816AD: fr_read_dir (menu-fentry.c:472) ==19085== by 0x807A211: init_menus (menu.c:142) ==19085== by 0x8062FA5: main (main.c:81) ==19085== which is in this code: if (entry != NULL) { g_assert (iter != NULL); if (real_fs_absolute_path_p) *real_fs_absolute_path_p = g_strdup (entry_get_absolute_path (entry)); if (entry_relative_name_p) *entry_relative_name_p = g_strdup (entry_get_relative_path (entry)); } at the end of this function: static PathResolution tree_node_find_subdir_or_entry (TreeNode *node, const char *name, TreeNode **subdir_p, char **real_fs_absolute_path_p, char **entry_relative_name_p) I don't see the two vars being used anywhere after g_strdup()ing stuff into them so I wonder if the allocation is bogus?
Created attachment 103103 [details] I think this is the patch for the other leak you point out
Thanks, I've committed the entry_set_unref()s upstream: 2004-08-25 Mark McLoughlin <mark> * src/menu-process.c: (resolve_legacy_dir), (tree_node_from_menu_node): don't leak the entry sets. Patch from Kjartan Maraas in rh bug #130673 * src/menu-method.c: (menu_method_get_info): free the resolved path. Another leak from rh bug #130673 and also a patch which i think should fix the other leak reported. I've only committed this stuff upstream because we have a bazillion patches in gnome-vfs2 for desktop-file-utils right now and we're in the process of cleaning that up. When we do, we'll pull in the leak fixes from upstream. Tiny tip Kjartan - diff -p makes it much easier to read patches :-)