GNOME Bugzilla – Bug 432386
GtkFileChooserDefault leaks memory if a shortcut cannot be found
Last modified: 2013-05-30 15:32:18 UTC
Please describe the problem: GtkFileChooserDefault tries to add two shortcuts by default: * /home/foo and * /home/foo/Desktop If these don't exist on the system, the respective row is removed from the list store, but the data in the list store entry isn't freed. Steps to reproduce: 1. rmdir ~/Desktop 2. GtkWidget w = gtk_file_chooser_dialog_new(..., GTK_FILE_CHOOSER_ACTION_OPEN, ...); 3. gtk_widget_destroy (w); Actual results: A gtk_file_path() instance is leaked. Expected results: No leak happens. Does this happen every time? Yes. Other information: When we remove the shortcut from the list store, we need to call shortcuts_free_row_data() on the entry. I think.
Created attachment 86799 [details] [review] Patch This patch is against 2.10.11. It works for me and looks correct, but it might not be the best way.
Hmm, it is possible that you are correct, but I don't see the leak in quick valgrind testing. How did you notice the leak ?
By running Valgrind :) Did you try to rmdir ~/Desktop? I'm pretty sure that should trigger it reliably.
Yes, I moved my ~/Desktop away
Strange. Does Valgrind complain about double-frees if you run with the patch applied?
Should this be marked as obsolete? I can't even see where the old patch should be applied. Looks like things have changed a lot since.
Great catch! This is certainly valid for the gtk-2-24 branch. I've pushed your patch as commit 3b82c12 in that branch. This bug totally slipped by my inbox; sorry that I let it lay dormant for years.