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
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