GNOME Bugzilla – Bug 588446
Preview of large video files freezes nautilus
Last modified: 2009-09-19 14:47:01 UTC
Please describe the problem: Clicking on a large video file (smallest reported was a 1.4GB avi file) while having "Other Previewable Files" enabled causes nautilus to freeze (it still can be forced to quit via the "X"-button). Steps to reproduce: 1. Create or download a large video file (another user found this 4.2GB mp4/1080p file from http://www.sitasingstheblues.com/watch.html to cause the bug which I can confirm). 2. Set "Other Previewable Files" to "Always" in nautilus's preview preferences. 3. Open the folder containing the video file and click on it (view mode doesn't matter). Actual results: Nautilus takes 100% CPU ("half" of my core duo system) and hogs memory (half of my 2GB). After some seconds it becomes unresponsive. I let it run for half an hour without any sign of progress. Expected results: Does this happen every time? Other information: Bug report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/397192
Created attachment 138324 [details] gdb attached to freezed nautilus (bt full, info registers, thread apply all bt)
Confirming with several 1.5 GB .mkv (video: x.264, audio: AC-3) files. Note that this bug even triggered when "Other previewable files" is set to "local only", and "only for files smaller than" to "5 MB". Only when "Other previewable files" is never this bug doesn't get triggered. A thumbnail gets generated in a "normal" amount of time, it is only after the display of the thumbnail that nautilus starts consuming lots of RAM and CPU.
*** Bug 592150 has been marked as a duplicate of this bug. ***
*** Bug 592751 has been marked as a duplicate of this bug. ***
Created attachment 141482 [details] gdb log showing "bt full" for all g_file_read_async and g_file_load_* calls leading up to the CPU spin For me it's sufficient to just right click a 7.5GB .mkv to make nautilus go into a CPU spin inside the function g_nearest_pow(). This happens because the "gint" datatype is not big enough to hold the value 2^31 and in my stacktrace I can see g_array_maybe_expand() running with the local variable wanted_alloc=1073750016 (which is bigger than 2^31). Clearly, allocating a 1GB byte array is a perfectly valid and sane use case (in certain special apps) so glib should NOT hang when this is attempted. However, I do not think it's appropriate for _nautilus_ to alloc 1GB in an array so we're actually dealing with both a glib bug and also a nautilus bug. I also tried to put the following breakpoints in nautilus: break g_file_read_async rbreak g_file_load_* ...and I then right clicked the 7.5GB file triggering the CPU spin. I'm attaching a gdb log showing "bt full" for all such BP hits. Note that every single one of these load/read breapoints are being hit from inside the nautilus function thumbnail_start(). I can repro this bug easily on my karmic machine so please let me know if there is anything I can do to provide more data about this bug.
Same problem in here. Nautilus 2.27.92 takes up to 100% CPU when clicking on large MKV file. It happens every time. Workaround - turn off preview.
This is fixed in HEAD. http://git.gnome.org/cgit/nautilus/commit/?id=a8097e57788ad735227489e6c51d06bedc796889
*** Bug 590307 has been marked as a duplicate of this bug. ***