Created attachment 157363 [details] First crash Hello, I installed digiKam 7.10.0 on Windows but I am getting multiple crashes when digiKam scans files on hard drive. The first crash I get is from libaom.dll When I remove kimg_avif.dll (to disable AVIF support), then I get second crash in liblibde265.dll
Created attachment 157364 [details] Second crash
Did you have this kind of image containers in your collections (AOM, AVIF, HEIF) ?
I have AVIF and HEIC files. After further examination I see that majority of HEIC files are working, only some of them trigger the crash. However, it seems that any AVIF file trigger the crash.
For HEIF, we have a dedicated loader in digiKam. We can investiguate where is the problem. For the other one, the loaders come from KF5::KImageFormat framework from KDE. Please share the suspected files using cloud.
I did an experiment. I replaced libaom.dll - I took file from msys2 project and AVIF files crashing previously started to work. MSYS2 builds 3.6.0 version, I think digiKam has v3.5.0. Can you try to upgrade libaom?
We need the corresponding images to investigate and fix the problem. If not public, to our e-mail addresses. Maik
Thank you for the sample image. This image does not crash with either digiKam7.10.0 or digiKam-8.0.0 here on Windows10. @Gilles, is it possible that libraries that are present in the Windows system are loaded instead of the ones in our digiKam program directory? As far as I know, our cross compiled libraries are not binary compatible. Do we possibly need to set a library search path? Maik
Due to the non binary compatibility with C++ objects, the OS libraries cannot be loaded instead. I'm sure. This is not the case for the pure C libraries, more and less, if ABI is compatible. But there is another case : on other application also cross compiled is installed on the system and used as well... We have only a qt conf file near the executable : https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/mxe/data/qt.conf That all. If we want to restrict the PATH to use the internal libraries, a batch file must be created to wrap executables. If i remember Firefox do it under Windows. Look also Krita which wrap executable in LNK files. there are binaries to start application: https://invent.kde.org/graphics/krita/-/tree/master/packaging/windows I think LNK files can do the job also. Gilles
Maik, As i can see, last Firefox under Windows to not use a startup wrapper script. It point directly on the application executable. How Firefox solve the possible issues if mixed libraries from different programs are installed on the system: mysterious... Gilles
The second sample image "crash_me.heic" also crashes here under Linux. Also with other programs that use the libheif. The crash is deep in the libheif library. This issue must be reported directly to the libheif team with the sample image. https://github.com/strukturag/libheif Maik
I think crash_me.heic crashes only with old libraries. Upgrade to latest libde265 should help.
which libde265 ? the rolling-release code from git or a specific release version of the lib ?
libde265 v1.0.11
ok, i will plan to update the libde265 to this version in all bundles asap... Gilles
Git commit 318709dfd65bd745ca5e3336f8ab21dd72ddc106 by Gilles Caulier. Committed on 25/03/2023 at 09:48. Pushed by cgilles into branch 'master'. update libde265 to 1.0.11 M +4 -4 project/bundles/3rdparty/ext_libde265/CMakeLists.txt M +10 -7 project/bundles/3rdparty/ext_libde265/libde265-lib-only.patch https://invent.kde.org/graphics/digikam/commit/318709dfd65bd745ca5e3336f8ab21dd72ddc106
Git commit a09a70153335c06e86e2d984ed9f70d5223e6778 by Gilles Caulier. Committed on 25/03/2023 at 12:35. Pushed by cgilles into branch 'master'. build Windows installer with KDE framework 5.104 and release service 22.12.3 M +2 -2 project/bundles/mxe/config.sh https://invent.kde.org/graphics/digikam/commit/a09a70153335c06e86e2d984ed9f70d5223e6778
Hi dnovomesky, I rebuild the whole MXE cross compiler on the Continuous Deployment computer. libde265 have been updated as the KF5 framework to tha last 5.104, to update the KImageFormats component including extra Qt image codecs. The Windows installer version 8.0.0 is uploaded at usual place: https://files.kde.org/digikam/ Please test and report if problem is fixed... Best regards Gilles Caulier
Hi Gilles, There is no longer a crash in the Windows version with this special HEIC image and it is also displayed "correctly". In addition to the HEIC image, dnovomesky also sent me a screenshot of an image viewer under Windows. Great. Maik
I tried the digiKam-8.0.0-20230325T124404-Win64.exe but I still have the problem with that AVIF file. I saw one case when digiKam loaded that file but I get crashes majority of time. Do you want to try upgrading the libaom to v3.6.0?
of course, i will do it
Git commit e58bc7ab40fe0c562d924343fa1e62c84edf5629 by Gilles Caulier. Committed on 26/03/2023 at 08:41. Pushed by cgilles into branch 'master'. update Libaom version to 3.6.0 under Windows M +3 -3 project/bundles/3rdparty/ext_libaom/CMakeLists.txt https://invent.kde.org/graphics/digikam/commit/e58bc7ab40fe0c562d924343fa1e62c84edf5629
Windows installer is now updated at usual place : https://files.kde.org/digikam/ Please test and report. Gilles Caulier
Good news! I installed digiKam-8.0.0-20230326T140515-Win64.exe and the AVIF works well. The most important problems are solved. Thanks! My suggestion is to upgrade the libheif too when it is convenient for you. (you may look at my PR: https://invent.kde.org/graphics/digikam/-/merge_requests/206 ). One option changed in libheif and there are some new options. In the past, I was able to trigger an assert when providing corrupted HEIC file. Fixed already in libheif (info in https://github.com/strukturag/libheif/issues/781 )
Ok, great. I close this file as original problem is solved. For the libheif rolling release usage in the bundle, please open a new remember file in bugzilla. Best Gilles