Created attachment 120809 [details] The corrupt png I have a large amount of photos library, about 16K or so, At first, importing all the folder seems fine, Then to make the thumbnail load faster I did the tool-> maintenance -> rebuild thumbnail ("with scan for changed" checked). It somehow keep crash after certain amount of percentage, Long story short, I import each folder manually, then I found 1 png file than cause DigiKam to crash whenever I add that file to the collection/folder, The png file seems fine and can be opened by windows 10 default photo library, BUT when I open it on Photoshop it show "IDAT:incorrect data check". I assume that the png image is corrupt, I attached the png file, STEPS TO REPRODUCE 1. Add the attached png file to album/folder 2. Run maintenance -> Rebuild thumbnail (Checked "scan for change") OBSERVED RESULT This file always crashed DigiKam SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Our error message "Internal libPNG error during reading file. Process aborted!" is not output under Windows. It looks like the error handling with setjmp/longjmp is not working. Maybe libpng has been compiled with PNG_SETJMP_NOT_SUPPORTED? Maik
Maik, Under Windows with MXE, the libpng rules are in this script : https://github.com/mxe/mxe/blob/master/src/libpng.mk There is no PNG_SETJMP_NOT_SUPPORTED passed as compilation flag... Gilles
Update, Everyone, thank you for your respond, So I open the png file on Autodesk Sketchbook then save as new file from it, then it solved, digiKam don't crash anymore with the new png file
OK, the cause is clear. When we install digiKam in the 32 bit version on a 64 bit Windows, everything works as expected. The PNG loader breaks off correctly and the error message is in the log and there is no crash. The cause is this bug in MinGW-w64: https://sourceforge.net/p/mingw-w64/bugs/406/ This also explains further crashes with digiKam under Windows. Maik
Created attachment 120825 [details] setjmp.patch One possibility is probably the use of the built-in GCC alternative __builtin_setjmp and __builtin_longjmp. I already provide the patch. The GDB Bugtrace shows that it crashes in libpng in the longjmp() function (jump into the msvcrt.dll, also confirmed by reports in the net) So we also have to patch the libpng. Maik
Maik, What's we can do with your patch ? It touch the DK image loaders. If they can be used as well, it's fine for me to commit and include change in Windows bundles. If libPNG need a patch too, it's more complicated as the patch must be sent to MXE team through github for normal UPSTREAM. Gilles
It should help for the JPG loader, but I will still test with a defective image. Exactly, libpng has a different error handling, the longjmp part is in the libpng, it should be patched. Should it work for the JPG loader, I will already use part of the patch. Maik
*** Bug 406979 has been marked as a duplicate of this bug. ***
*** Bug 411763 has been marked as a duplicate of this bug. ***
digiKam 7.0.0 stable release is now published and now available as FlatPak: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Problem fixed as reported in bug #406979