GNOME Bugzilla – Bug 314852
nautilus hangs when opening folder w/ specific TIFF file
Last modified: 2011-12-16 23:21:08 UTC
Version details: nautilus-2.10.0-4 Distribution/Version: Fedora Core 4 Browse to a folder that contains this TIFF, and Nautilus hangs and eats 99% CPU. Other Nautilus windows become equally useless. I'm guessing at the component. I have two different TIFFs that show this problem. Evince can open both files. Unfortunately, I can't upload either because they contain sensitive information. I could e-mail one file to a developer directly, or I can upload it to the bugzilla if the bug is made private (e.g., with a security flag). For now, here are some details on the TIFFs. $ identify -verbose spss-license.tif spss-license.tif TIFF 2528x3296 PseudoClass 2c 27kb 0.370u 0:01 Image: spss-license.tif Format: TIFF (Tagged Image File Format) Geometry: 2528x3296 Class: PseudoClass Type: Bilevel Endianess: LSB Colorspace: Gray Channel depth: Gray: 1-bits Channel statistics: Gray: Min: 0 (0) Max: 1 (1) Mean: 1.20015e-07 (1.20015e-07) Standard deviation: 0.000346432 (0.000346432) Colors: 2 Histogram: 341856: ( 0, 0, 0) black 7990432: (255,255,255) white Rendering-intent: Undefined Resolution: 300x300 Units: PixelsPerInch Filesize: 27kb Interlace: None Background Color: white Border Color: #DFDFDF Matte Color: grey74 Dispose: Undefined Iterations: 0 Compression: Group4 Orientation: TopLeft Signature: 754ad3c833d6e3feb83ed1e4c22fa3b434f86dc0cc6fd3dffdc14b1bab35892e Software: V1.13 May 31 1999 Tainted: False Version: ImageMagick 6.2.2 06/21/05 Q16 file:/usr/share/ImageMagick-6.2.2/doc/ index.html $ identify -verbose power-of-attorney.tif power-of-attorney.tif TIFF 2528x3296 PseudoClass 2c 27kb 0.360u 0:01 Image: power-of-attorney.tif Format: TIFF (Tagged Image File Format) Geometry: 2528x3296 Class: PseudoClass Type: Bilevel Endianess: LSB Colorspace: Gray Channel depth: Gray: 1-bits Channel statistics: Gray: Min: 0 (0) Max: 1 (1) Mean: 1.20015e-07 (1.20015e-07) Standard deviation: 0.000346432 (0.000346432) Colors: 2 Histogram: 148499: ( 0, 0, 0) black 8183789: (255,255,255) white Rendering-intent: Undefined Resolution: 300x300 Units: PixelsPerInch Filesize: 27kb Interlace: None Background Color: white Border Color: #DFDFDF Matte Color: grey74 Dispose: Undefined Iterations: 0 Compression: Group4 Orientation: TopLeft Signature: b211da3ae5aa43615c262053d3131546db8a7667ade28d06f2d56f32b7971763 Software: V1.13 May 31 1999 Tainted: False Version: ImageMagick 6.2.2 06/21/05 Q16 file:/usr/share/ImageMagick-6.2.2/doc/index.html
Whoops! Nautilus doesn't crash, it just takes a very long time to generate the thumbnails. For a folder containing only the two trouble TIFFs (each only 27kb, one page scans), I gave up timing after 5 mins. Reducing severity accordingly.
Bug has been marked private. Please attach the TIFF files.
Created attachment 51566 [details] TIFF #1 for which thumbnailing is slow Here's one of the TIFFs. I hope it's enough for debugging.
I think the problem is just that the image has a very high resolution (2528x3296). The file itself is just monochrome, which is one bit per pixel, meaning about one meg uncompressed. However, loading it with gdk-pixbuf means we're loading it as a 24bit file, resulting in an uncompressed in-memory version of 65 megabytes, which we then scale down to a small size. On my box the file thumbnails pretty much instantly. Maybe the speed is affected by lack of memory leading to swapping. How much memory do you have? You can test if this is related to the image itself by just generating a totally white image of the same type and size. Is this also slow to thumbnail?
Bug 134544 is probably related.
Created attachment 51636 [details] blank TIFF that takes too long to thumbnail All-white (as white as this scanner can get it) scan, which exhibits the same problem.
Detailed information about the blank TIFF. $ identify -verbose image.tif image.tif TIFF 2528x3296 PseudoClass 2c 12kb 0.370u 0:01 Image: image.tif Format: TIFF (Tagged Image File Format) Geometry: 2528x3296 Class: PseudoClass Type: Bilevel Endianess: LSB Colorspace: Gray Channel depth: Gray: 1-bits Channel statistics: Gray: Min: 0 (0) Max: 1 (1) Mean: 1.20015e-07 (1.20015e-07) Standard deviation: 0.000346432 (0.000346432) Colors: 2 Histogram: 6188: ( 0, 0, 0) black 8326100: (255,255,255) white Rendering-intent: Undefined Resolution: 300x300 Units: PixelsPerInch Filesize: 12kb Interlace: None Background Color: white Border Color: #DFDFDF Matte Color: grey74 Dispose: Undefined Iterations: 0 Compression: Group4 Orientation: TopLeft Signature: 2767f12ff185bb458481ce2e64d03344a451aa28cfd00bff342eadd582e3c19d Software: V1.13 May 31 1999 Tainted: False Version: ImageMagick 6.2.2 06/21/05 Q16 file:/usr/share/ImageMagick-6.2.2/doc/ index.html
I doubt that it's lack of memory. Mem: 506820k total, 501000k used, 5820k free, 55128k buffers Swap: 524280k total, 7716k used, 516564k free, 200060k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2691 luser 25 0 140m 112m 11m R 99.5 22.7 5:14.54 nautilus This is a P4 box, probably 2.4Ghz.
I can reproduce it on HEAD. Both tiffs basically freeze nautilus here with 100% CPU. The call to gdk_pixbuf_scale_simple() in scale icon() seems to go into an infinite loop. Might be the funky Group4 compression?
We're changing group security for all "secret" bugs from the "hackers" group to the product-specific Developers group.
*** This bug has been marked as a duplicate of bug 666391 ***