| Summary: | Digikam seg faults building thumbnail from gigabyte PNG | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Brad Templeton <kde-id> |
| Component: | Plugin-DImg-PNG | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 7.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/commit/d43bae44fbf3d4f0c23ab8a9310ec6d3d415e33d | Version Fixed In: | 7.2.0 |
| Sentry Crash Report: | |||
| Attachments: | The output of digikam and gdb on seg fault | ||
Can you give us the ouput of ImageMagick tool "identify" with this PNG file. The command line is "idenify -v _foo_.png" Best regards Gilles Caulier Image: big4.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 49494x15588+0+0
Units: Undefined
Colorspace: sRGB
Type: TrueColor
Base type: Undefined
Endianess: Undefined
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Pixels: 771512472
Red:
min: 0 (0)
max: 255 (1)
mean: 97.7906 (0.383493)
standard deviation: 51.0469 (0.200184)
kurtosis: -1.15167
skewness: 0.224519
entropy: 0.925188
Green:
min: 0 (0)
max: 255 (1)
mean: 133.99 (0.525452)
standard deviation: 56.1589 (0.220231)
kurtosis: -1.34467
skewness: -0.312729
entropy: 0.907559
Blue:
min: 0 (0)
max: 255 (1)
mean: 162.729 (0.638155)
standard deviation: 63.0851 (0.247392)
kurtosis: -1.10013
skewness: -0.440393
entropy: 0.909048
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 131.503 (0.5157)
standard deviation: 56.7636 (0.222602)
kurtosis: -1.20481
skewness: -0.014954
entropy: 0.913932
Rendering intent: Perceptual
Gamma: 0.454545
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Background color: white
Border color: srgb(223,223,223)
Matte color: grey74
Transparent color: black
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 49494x15588+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2020-09-27T18:24:45-07:00
date:modify: 2010-06-02T15:39:54-07:00
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 49494, 15588
png:sRGB: intent=0 (Perceptual Intent)
signature: 030a41cc6a75a15071b9c4be6019c8405e0a8c2492b592f553381b8a8c87b2a2
Artifacts:
filename: big4.png
verbose: true
Tainted: False
Filesize: 1.00509GiB
Number pixels: 771.512M
Pixels per second: 52.1998MB
User time: 13.340u
Elapsed time: 0:15.780
Version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
Let me add I do have a very fast internet connection, so if you really want the gigabyte file, I can make it available for you -- I just figured you might want to look for something obvious at the designated point in the backtrace before asking for that. Thanks for the feedback. It's a huge image. How did you generate this file ? Panorama ? It's a landscape ? It's a astro photo ? Can you open the file in ImageMagik "display" command line tool ? Gilles Caulier The crash is located in libpng at end. It pass in thumbnail engine, and in DImg plugin to load PNG file, and finaly libpng. This is can be due of digiKam DImg plugin to handle memory with libpng, or the way to catch exceptions from libpng. Gilles Caulier Correct. It is a near-gigapixel panorama. I have hundreds of these and most don't cause a problem, though I usually have them as tiff or when they fit, jpg If it is too large for digikam, that is understandable. Display does not handle it. I don't know how I made the png, possibly in gimp or convert from a tiff. Of course, digikam must not seg fault on it, however, and should just treat it as a file it can't handle displaying what it can. However, as I said this file is a decade old, and has been in my digikam archives all that time, and never caused it to seg fault. Looking at other large files it is not doing a good thumbnail, but as I say, I can understand if it is too large for that. (I would like to still be able to move such images around, add captions etc. if needed.) BTW, display doesn't crash, just displays a full sized gray window but it does show a little thumbnail of it. If you want to work with it and have the bandwidth, it will be uploaded to http://www.templetons.com/etc/big4.png Upload should complete in 4 minutes, rsync says, but that varies so let me update when it's there. The upload is now complete at http://www.templetons.com/etc/big4.png if you really want to test on the actual file. Note that while catching exceptions in the plugin is a good idea to avoid segfault of all of digikam, I have a suspicion it takes some time to fault, and you would not want to have it try and fail repeatedly. Which means that after such a failure, you might want to produce a fake "failed" thumbnail so it doesn't try again until you do a rescan. If it do not crash in ImageMagick, it must not crash in digiKam PNG plugin. Both use libpng, so the behavior must be the same. Thanks to share the PNG file, this will help to investigate. Gilles Caulier The problem is here: https://invent.kde.org/graphics/digikam/-/blob/master/core/dplugins/dimg/png/dimgpngloader_load.cpp#L526 The loop variable must be at least uint. Because i * (int)width * 8 exceeds the range of integer. Tonight I will test whether the DImg scaling function has problems with this image. Maik Git commit d43bae44fbf3d4f0c23ab8a9310ec6d3d415e33d by Maik Qualmann. Committed on 28/09/2020 at 10:34. Pushed by mqualmann into branch 'master'. fix memory pointer calculation in the DImg PNG loader FIXED-IN: 7.2.0 M +2 -2 NEWS M +2 -2 core/dplugins/dimg/png/dimgpngloader_load.cpp https://invent.kde.org/graphics/digikam/commit/d43bae44fbf3d4f0c23ab8a9310ec6d3d415e33d Are 32 bit systems still supported for digikam? If yes, it might make sense to 1) use quintptr to not force 64 bit arithmetic on 32 bit systems 2) add a range check and error out properly instead of blindly adding a 64 bit value to a 32 bit address and hoping that it works. Yes, quintptr is a good indication. In the function for memory allocation it is checked whether it is possible for the architecture. Here in the PNG loader, too, the function would have been exited under 32 bit because the memory cannot be allocated. Maik Git commit 6d3365d72054253d73c8aac223f91081415166f2 by Maik Qualmann. Committed on 28/09/2020 at 18:42. Pushed by mqualmann into branch 'master'. use quintptr to prevent 64 arithmetic on 32 bit platforms M +2 -2 core/dplugins/dimg/png/dimgpngloader_load.cpp https://invent.kde.org/graphics/digikam/commit/6d3365d72054253d73c8aac223f91081415166f2 |
Created attachment 131975 [details] The output of digikam and gdb on seg fault SUMMARY For the past several weeks, digikam has been segfaulting about 10 seconds after I start it, even when I change what folder is under view. It appears to be rebuilding thumbnails. To see if I could fix it, I ran in the 7.2 beta appimage and the fault still occurs. STEPS TO REPRODUCE 1. Run digikam (in my photo albums, alas) 2. Wait 10 seconds 3. OBSERVED RESULT Seg fault. It seems to fault building a thumbnail for a very large PNG. This file has been present for a decade in many versions of digikam. However, when I move that file out of my archives it no longer faults so that is the cause. Of course, I don't really want to give you a gigabyte file, but will if it is the only way to diagnose. EXPECTED RESULT Not seg fault SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION