crash if thumbnailer fails to produce output

[Misaki]

Step 1: Use a custom thumbnailer which doesn't always produce output. I'm personally using this one, since the default size (256x256) often produces a png thumbnail which takes more space than the original jpg image, and imagemagick's convert seems to have a bug for palette-png to grayscale conversion:

[Thumbnailer Entry]
TryExec=ffmpeg
Exec=ffmpeg -i %i -vf "scale='min(iw,128):min(ih,128):force_original_aspect_ratio=decrease',format=rgba|rgb24" -frames 1 -y -f image2 -c:v png %o
MimeType=image/gif;image/jpeg;image/png;image/jp2;image/x-webp

Step 2: navigate to a folder that the thumbnailer can't handle. For me, that was "balloon.jp2" from http://opf-labs.org/format-corpus/jp2k-formats/

My version of ffmpeg says on the command line that "Progression order RPCL is not implemented. [...] Output file is empty, nothing was encoded". Not having any file from the thumbnailer, or maybe having an empty, 0-byte file (ffmpeg does not produce a 0-byte output file from the command line), causes nautilus to freeze and crash.

This happened multiple times. However, just now I checked and it didn't crash, and a thumbnail exists for the jp2 image, /sigh. But creating a copy of the jp2 image does lead to crashes. Ok, the reason is that eog creates a thumbnail when one doesn't exist and the system's default thumbnailers fail. Opening the image gallery in eog causes thumbnails to be created for all visible images.

That is, when running eog from a terminal, opening the image gallery caused ffmpeg's output (with the error message) to be displayed in that terminal. But the thumbnail is still created, and eog must have done it.

It's also possible nautilus crashes when the fallback gnome-thumbnailer fails to create a file, which I think is what happens when it tries to open a jpeg-2000 file. A few months ago I noted this bug:

>Another bug, crashes when trying to generate thumbnail for jpeg-2000 (jp2). Avoided if thumbnail is already created, maybe in some other cases too. Possibly just when thumbnail isn't created quickly enough (thumbnailer fails or something).

...but apparently I fixed it somehow, not sure.

So it's totally fine that no thumbnail is created when the existing thumbnailer entries aren't sufficient. But nautilus shouldn't crash. When running nautilus from the command line, it says there was a segmentation fault, core dumped, with a crash file being generated in /var/crash (which I'm deleting).

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 15 20:48:20 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b"['name', 'size', 'date_modified', 'date_accessed', 'type']"
 b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions']"
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

[Misaki (myjunkmail311006)]

After removing custom thumbnailers, copying a jp2 file using ctrl-C ctrl-V causes nautilus to crash about one time. gnome-thumbnailer tries to create a thumbnail, but it can take several seconds, and if nautilus is reopened and navigated to that folder again, it will crash again. However, after this has been completed, nautilus won't crash. (In fact, top reveals that it's eog that creates the new thumbnail if you use ctrl-C ctrl-V in nautilus.)

If the new file name is obtained a different way, like using 'mv' on the command line, navigating to that folder in nautilus will cause a crash without attempting to generate a new thumbnail.

So even if you wait several seconds, no thumbnail will exist for the file and nautilus will crash every time you navigate to that folder until you delete the file or rename it to a path for which it will have a valid thumbnail (meaning the file's mtime is correct).

So this might only affect jpeg-2000 files, and not all files for which there is no valid output. Maybe with other files, the default thumbnail options (the ones not recorded in /usr/share/thumbnailers) consistently create at least a failed thumbnail, while this doesn't happen with jpeg-2000 files. But since nautilus is crashing before eog finishes creating a thumbnail (if using ctrl-C ctrl-V to copy), nautilus might be relying on a separate process from what it depends on for, say, obtaining a 'failed thumbnail' result for incomplete mp4 files, which don't cause a crash.

One difference is that while gnome-thumbnailer has code for handling image formats as a fallback method, it isn't for video formats. I'm not sure if it's nautilus or gnome that's calling eog to create a thumbnail when ctrl-C ctrl-V is used.

[Misaki (myjunkmail311006)]

If you rename a jp2 file to jpg, it doesn't cause nautilus to crash. It just shows the 'generic image' icon that's also used if an image is larger than the limit set for previewing, and eog is unable to open it.

If a jp2 file is renamed to have a non-image suffix, nautilus will be busy (100% cpu) for a second or two and then the image will use the 'generic icon', without nautilus crashing. With image suffixes, this doesn't occur.

I also managed to replicate a bug that I avoided reporting earlier because I couldn't replicate it again. A png image has a 'corrupted' thumbnail, what is obviously the result of the file being read in an unfinished state. That is, gnome-thumbnailer or nautilus, or whatever is creating thumbnails, should be waiting until a file's modification time is 3 seconds in the past before trying to create a thumbnail for it, based on the code I looked at. This seems to work for video files, but not for images. When this happened before I verified that the difference between the modification time for the thumbnail (now in ~/.cache/thumbnails in Ubuntu, previously in ~/.thumbnails), and the time for the file as recorded in the thumbnail's PNG data and the same as for the actual file, was less than three seconds, being around 1 second. Maybe nautilus is not using this code though.

[Sebastien Bacher (seb128)]

Do you still see that issue in newer Ubuntu versions?

[Launchpad Janitor (janitor)]

[Expired for nautilus (Ubuntu) because there has been no activity for 60 days.]