GNOME Bugzilla – Bug 307138
leaks in nautilus 2.11.x
Last modified: 2005-06-11 11:47:00 UTC
==8732== 15 bytes in 1 blocks are definitely lost in loss record 5357 of 20645 ==8732== at 0x1B909222: malloc (vg_replace_malloc.c:130) ==8732== by 0x1C4E8F55: g_malloc (gmem.c:137) ==8732== by 0x1C4F974F: g_strconcat (gstrfuncs.c:229) ==8732== by 0x1B948775: nautilus_file_operations_progress_new_file (nautilus-file-operations-progress.c:575) ==8732== by 0x1B948F63: progress_dialog_set_to_from_item_text (nautilus-file-operations.c:376) ==8732== by 0x1B94B447: handle_transfer_ok (nautilus-file-operations.c:441) ==8732== by 0x1C13DD67: dispatch_sync_job_callback (gnome-vfs-job.c:283) ==8732== by 0x1C4E4FFF: g_idle_dispatch (gmain.c:3812) ==8732== by 0x1C4E2E5D: g_main_context_dispatch (gmain.c:1933) ==8732== by 0x1C4E5C2D: g_main_context_iterate (gmain.c:2564) ==8732== by 0x1C4E612E: g_main_loop_run (gmain.c:2768) ==8732== by 0x1BDD0464: gtk_main (gtkmain.c:974) ==8732== by 0x8070E89: main (nautilus-main.c:434)
Created attachment 47537 [details] [review] possible patch This looks like it should fix it. I added a call to free the item_markup also even though that's not in the valgrind backtrace.
Created attachment 47595 [details] [review] updated patch Found some more
Another leak: I see this trace from running nautilus under valgrind: ==8405== 5 bytes in 1 blocks are definitely lost in loss record 180 of 5529 ==8405== at 0x1B909222: malloc (vg_replace_malloc.c:130) ==8405== by 0x1C4E8F55: g_malloc (gmem.c:137) ==8405== by 0x1C4F95D6: g_strndup (gstrfuncs.c:125) ==8405== by 0x1C4F9F38: g_ascii_strdown (gstrfuncs.c:1513) ==8405== by 0x1C14D96E: get_method_string (gnome-vfs-uri.c:423) ==8405== by 0x1C14DBE5: gnome_vfs_uri_new_private (gnome-vfs-uri.c:554) ==8405== by 0x1C14DE3A: gnome_vfs_uri_new (gnome-vfs-uri.c:531) ==8405== by 0x8081068: nautilus_window_initialize_menus (nautilus-window-menus.c:232) It seems the method_string from gnome_vfs_uri_new_private() is not free'd somewhere along the way: /* The toplevel URI element is special, as it also contains host/user information. */ uri->method = method; uri->ref_count = 1; uri->method_string = method_string; uri->text = NULL; uri->fragment_id = NULL; The only place I see this being freed is in destroy_element() which is called from gnome_vfs_uri_unref(), so we seem to be missing a gnome_vfs_uri_unref() call somewhere? maybe in nautilus_window_finalize()? It's allocated here: static gboolean have_burn_uri (void) { static gboolean initialized = FALSE; static gboolean res; GnomeVFSURI *uri; if (!initialized) { uri = gnome_vfs_uri_new ("burn:///"); res = uri != NULL; if (uri != NULL) { gnome_vfs_uri_unref (uri); } initialized = TRUE; } return res; }
The above code correctly unrefs the uri though. Don't know what's happening here...
Comment on attachment 47595 [details] [review] updated patch Looks fine, please commit on both branches.
I glanced over the method_string/uri stuff and couldn't spot the leak either.
Commited to HEAD and the relevant bits to stable (the emblem stuff)