GNOME Bugzilla – Bug 685438
Background settings page will attempt to load huge images into memory
Last modified: 2015-10-27 12:37:46 UTC
I have a 46 megabyte .png sitting in my ~/Pictures folder (which itself is 5.4G in size) and, unless I remove that file, the appearance applet chugs away until it's consuming 1.5G or so of RAM. Checking whether the file is above a certain size (perhaps determined from the same setting nautilus uses when deciding whether to generate previews?) should fix it.
Can you upload that file somewhere, even temporary, for me to be able to download and reproduce the bug?
Even better, http://fishface.org.uk/static/images/huge.png (62KB) is a plain, white, massive-resolution PNG that exhibits the bug. Some more information gained from this: the problem occurs strictly after generating the thumbnail; the first time the applet starts, it takes a while (but not an unreasonable length of time given the size of the image) to generate a thumbnail, after which the thumbnails start displaying in the applet, and memory usage starts increasing. The other thing I learnt is that creating a 31000x16000 pixel PNG takes a looong time!
I can not reproduce this anymore with current Git master. Maybe this is a duplicate of bug 709243 ? Do you still experience this problem with recent versions? Say 3.8 or 3.10.
(In reply to Chris Le Sueur from comment #2) I created three copies of the attached file and didn't see the memory usage continue to grow. Nothing in valgrind either [*]. > Some more information gained from this: the problem occurs strictly after > generating the thumbnail; the first time the applet starts, it takes a while > (but not an unreasonable length of time given the size of the image) to > generate a thumbnail, after which the thumbnails start displaying in the > applet, and memory usage starts increasing. The last bit makes me even more suspicious that this was one of the leaks fixed in bug 709243 [*] I did find a few smaller leaks, but none that would lead to the symptoms mentioned here. *** This bug has been marked as a duplicate of bug 709243 ***