GNOME Bugzilla – Bug 774232
nautilus progressively uses more and more memory while moving large amounts of files between disks.
Last modified: 2021-06-18 15:47:54 UTC
Created attachment 339545 [details] valgrind log while moving 160k files between two hard disks. nautilus progressively uses more and more memory while moving large amounts of files between disks. moving 160k files totalling 1GB consumed 60~MB and it was not released at the end. I have a valgrind log. Note: This isn't the end of the world since nautilus can be easily restarted. There are some gvfsd-metadata leaks that are probably higher priority. But I thought I should file a report in case the root cause is the same.
Created attachment 339722 [details] [review] file: unref emblem The emblem acquired in apply_emblems_to_icon () is not unreffed as it should be, since g_emblemed_icon_add_emblem () adds a ref to it.
Created attachment 339723 [details] [review] clipboard: free item list The item list in nautilus_clipboard_is_cut_from_selection_data () is never freed.
While not directly related, these are visible in the log.
Created attachment 339724 [details] new valgrind log. moving files then deleting them. I have a new valgrind log with the patches. I moved 1.4K files then deleted them.
Created attachment 339744 [details] [review] file-operations: free delete progress details string The details string in report_delete_progress is not being freed after use.
This also appears in your log a lot.
Created attachment 339745 [details] [review] file: unref emblem The emblem acquired in apply_emblems_to_icon () is not unreffed as it should be, since g_emblemed_icon_add_emblem () adds a ref to it.
Created attachment 339746 [details] [review] clipboard: free item list The item list in nautilus_clipboard_is_cut_from_selection_data () is never freed.
Review of attachment 339744 [details] [review]: This is wrong, no string from ngettext should be freed.
(In reply to Carlos Soriano from comment #9) > Review of attachment 339744 [details] [review] [review]: > > This is wrong, no string from ngettext should be freed. ngettext? It comes from f().
(In reply to Ernestas Kulik from comment #10) > (In reply to Carlos Soriano from comment #9) > > Review of attachment 339744 [details] [review] [review] [review]: > > > > This is wrong, no string from ngettext should be freed. > > ngettext? It comes from f(). As in, there is a call to eel_strdup_vprintf_with_custom ().
ooooh, the issue is that we don't do "take_details" but "set_details", we should change that to take_details :) Sorry I was in a confused state looking at the ownership.
Review of attachment 339745 [details] [review]: yeah thanks!
Review of attachment 339746 [details] [review]: Looks good, thanks!
(In reply to Carlos Soriano from comment #12) > ooooh, the issue is that we don't do "take_details" but "set_details", we > should change that to take_details :) > Sorry I was in a confused state looking at the ownership. Ah, yes, I totally overlooked it!
Created attachment 340639 [details] [review] file-operations: free delete progress details string The details string in report_delete_progress is not being freed after use.
Created attachment 340640 [details] [review] file-operations: take progress details string Progress info details are set instead of taken, resulting in a string leak.
Attachment 339745 [details] pushed as 2dc2983 - file: unref emblem Attachment 339746 [details] pushed as 12476f4 - clipboard: free item list
It would be great if someone else could find the time to investigate this further, since it’s that busy time of the year again for me.
Review of attachment 340640 [details] [review]: yay :D
feel free to backport to 3.22
Comment on attachment 340640 [details] [review] file-operations: take progress details string Attachment 340640 [details] pushed as 71ef6d3 - file-operations: take progress details string
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.