Comment 45 for bug 204413

I can confirm this bug and reliably reproduce it, after suffering from it for a long time seemingly randomly without understanding what caused it, and finally noticing a strange coincidence tonight (see below).

Also I can maybe tell why and how it happens by guesswork ...

=== Conditions to reproduce the bug ===
* nautilus in icon view, with thumbnails enabled,
* any video file for which nautilus has had a thumbnail generated

At this step the tentative conclusion is that the bug is related to video thumbnailing support, however the totem-video-thumbnailer program seems fine, and is not executed by nautilus when the bug happen anyway.

=== First method to trigger the bug ===
* Select the video file in a nautilus window or on the desktop
Symptoms:
* lots of disk accesses happen
* meanwhile nautilus' resident memory progressively increase by *exactly* the size of the video file, as reported by gnome-system-monitor (this is usually barely noticeable with small video files but gets problematic with 4GB ones ...)
* it then frees all the memory allocated during the previous step

* changing folder or closing the nautilus window during step 2 is generally enough to interrupt the process and make it restore the allocated memory prematurely.

That leads me to the tentative conclusion that nautilus is copying the file entirely in its memory, to do stuff with it. The question remaining is then what could that stuff be ?

=== Second method to trigger the bug ===
* increase the zoom level to over 150% (ie from 200% upward)
Symptoms:
* same as with first method, seemingly with each video file in the folder one at a time when there is more than one present

A few considerations:
* Thumbnails generated by totem-video-thumbnailer (the png files in ~/.thumbnails) are all 128px wide (the 'normal' size subfolder);
* at 100% zoom level, they are displayed by nautilus at width 96px, at 150% it's 128px wide.

* Nautilus does thumbnailing of image files internally (without calling an external helper like it does for videos), and also store 128px wide thumbnails for image files;
* when needed, ie when zoom level is over 150%, it automatically rereads image files to provide non-blurry thumbnails with higher resolutions, which it seems to only keep in memory (these do not end in ~/.thumbnails).

=== Conclusion: how the bug happen (plausibly) ===
* Nautilus has a routine for regenerating thumbnails of higher resolutions when zooming in, which for some reason is also called when simply selecting a file (as a preemptive step maybe ?)
* This routine works by copying all the content of the file to be thumbnailed into memory (which seems unavoidable for an *image* file)
*** the bug is here *** That routine is called by nautilus for all files which have a thumbnail, without checking the filetype first (silly nautilus)
* As a consequence, the entire video file is copied into memory, before nautilus (or maybe gdk-image-loader or whatever it's called) realize it doesn't know what to do with it and frees the memory.

As an aside this means one could theoretically reproduce this bug with files of any type, as long as they are thumbnailed (and not directly by nautilus like image files) and are large enough for the bug to be noticeable, however those conditions are only ever fulfilled in practice by videos.