Created attachment 66629 [details] [review]
Missing gtk_file_system_volume_free

On closer inspection, that is not the right fix since the volume is actually put into the shortcuts_models, AIUI...

Anyway, valgrind definitely thinks it's lost...
==19569== 2 bytes in 1 blocks are definitely lost in loss record 23 of 14,955
==19569==    at 0x40051F9: malloc (vg_replace_malloc.c:149)
==19569==    by 0x4537AF5: g_malloc (gmem.c:131)
==19569==    by 0x454ADC8: g_strdup (gstrfuncs.c:91)
==19569==    by 0x5AD8EDF: (within /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x59341E3: gtk_file_system_get_volume_for_path (in /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x591B654: (within /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x5ADAC3D: (within /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x452E8E0: g_idle_dispatch (gmain.c:3909)
==19569==    by 0x4530651: g_main_context_dispatch (gmain.c:2028)
==19569==    by 0x453361E: g_main_context_iterate (gmain.c:2660)
==19569==    by 0x45339C8: g_main_loop_run (gmain.c:2864)
==19569==    by 0x5986423: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.901.0)

Not to mention the leak of handles from gtk_file_system_get_info...
==19569== 1,200 bytes in 60 blocks are definitely lost in loss record 14,774 of 14,955
==19569==    at 0x40051F9: malloc (vg_replace_malloc.c:149)
==19569==    by 0x4537AF5: g_malloc (gmem.c:131)
==19569==    by 0x45477E7: g_slice_alloc (gslice.c:783)
==19569==    by 0x4547B47: g_slice_alloc0 (gslice.c:792)
==19569==    by 0x44F0099: g_type_create_instance (gtype.c:1547)
==19569==    by 0x44D6631: g_object_constructor (gobject.c:1015)
==19569==    by 0x44D49D9: g_object_newv (gobject.c:912)
==19569==    by 0x44D54DE: g_object_new_valist (gobject.c:955)
==19569==    by 0x44D568F: g_object_new (gobject.c:793)
==19569==    by 0x5ADAA3D: (within /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x5ADB568: (within /usr/lib/libgtk-x11-2.0.so.0.901.0)
==19569==    by 0x59343EF: gtk_file_system_get_info (in /usr/lib/libgtk-x11-2.0.so.0.901.0)
which may well just be the unexecuted callbacks? But I suspect not, as inside shortcuts_insert_path: 
handle = gtk_file_system_get_info()
...
gtk_list_store_set(impl->shortcuts_model, &iter,
  SHORTCUTS_COL_HANDLE, handle,
  -1);
<no g_object_unref(handle);>
return;
where the column type for SHORTCUTS_COL_HANDLE is G_TYPE_OBJECT hence the store acquires its own reference and we do not release ours.

Created attachment 66630 [details] [review]
Add g_object_unref(handle)

I suspect that there are many more handle leaks inside gtkfilechooserdefault...

For example:
impl->file_list_drag_data_received_handle and co are assumed to be unref'ed by gtk_file_system_cancel_operation, which it doesn't.

And reading the code again reveals shortcut_free_row_data which is meant to close the leaks I mentioned earlier...

Created attachment 66647 [details] [review]
Call g_object_unref after gtk_file_system_cancel_operation

Am I getting closer? I still think the reference handling through the list store is confused and needs closer inspection - actually all the g_object_unref needs careful review by someone who actually understands the code...

Created attachment 66648 [details] [review]
Again, without the erroneous volume_free

*** This bug has been marked as a duplicate of 348113 ***