SUMMARY DigiKam crashes whenever I start it. "Finding New Items" gets to 74% and then the programme crashes. No logs are left (that I can find). exiftool.exe is left running as a background process. STEPS TO REPRODUCE 1. Start DigiKam 2. Wait until "Finding New Items" progress bar gets to 74% OBSERVED RESULT Programme crashes, with no error message or logs. EXPECTED RESULT Programme should continue running :-) SOFTWARE/OS VERSIONS Windows: 11 Pro macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Please create a DebugView log so we can identify the last file scanned to reproduce the issue. The creation of the DebugView log is described here, don't forget to set the Qt debug environment variable: https://www.digikam.org/contribute/ Maik
Created attachment 160006 [details] DebugView Log
The log shows no debug messages, only minor warnings. The Qt debug variable is not set correctly in the Windows environment variable editor: This entries must be entered as user environment variables, without the quotation marks. name: "QT_LOGGING_RULES" value: "digikam*=true" Maik
Created attachment 160007 [details] Control Panel > System > Advanced
Created attachment 160008 [details] msinfo32
Have added screenshots from Control Panel and from sysinfo32 which appear to show that QT_LOGGING_RULES is set to digikam*=true. Am I doing something wrong? I'm still getting the same output from DebugView when I start DigiKam.
The variable seems to be set correctly. We recently had the same issue of not being able to turn on debug output. I need to test if it is related to Windows11. Maik
Created attachment 160017 [details] DebugView log from debug version of DigiKam Thanks. I just realised that I was running digiKam-8.1.0-20230628T051544-Win64.exe and not digiKam-8.1.0-20230628T051544-Win64-debug.exe. I have installed the -debug version and attach the (74Mb, so I have had to compress it) log file produced when I run DigiKam.
Oh, what binary data is there in the log, your thumbnail database is broken. The thumbnail database can no longer be repaired with the error number, delete the file "P:/thumbnails-digikam.db". The database is rebuilt automatically on the fly or with the maintenance tool. Activate the new "WAL" mode in the digiKam settings under Database. Also check your drive (P:) for hard disk errors. Note: the "-debug" package is not necessary for debug output. The "-debug" stands for debug symbols to have better code tracing with a debugger. Maik
Many thanks. I have deleted the file "P:/thumbnails-digikam.db" - but DigiKam still crashes at 74% when I start it. I also don't have enough time to make any changes in Settings before DigiKam crashes (it takes about 12 seconds from first screen until crash). I have checked P: (which is actually a link to Z:\PHOTOGRAPHS, just in case that matters) and there are no errors. Thank you for the explanation regarding the -debug version; as it created a much larger log file than the non-debug version, I had assumed that it was required.
Ok, please create a new log. Maik
In the first log, "D:/Temp/86.avif" was the last file scanned. The AVIF file could be the problem. Maik
Created attachment 160033 [details] 86.avif file which reliably causes DigiKam to crash I deleted the D:\temp\86.avif file and it does indeed appear to be the problem. When I delete it, DigiKam reliably opens and when I restore it, DigiKam crashes. I have attached the file in case it is of use. Thank you VERY much for all your help!
Thanks for testing and the sample AVIF image. I can't reproduce a crash here on Windows 10 in a VM. But with AVIF this can also depend on the processor. I will test it on real Windows machines in the next few days. The problem has already been reported, so I'm closing the bug as a duplicate. Note: disable debug logging, it makes digiKam slower on Windows. Maik *** This bug has been marked as a duplicate of bug 471269 ***
I tried digiKam-8.1.0-20230628T051544-Win64.exe and I also get the crash. The crash is inside libaom.dll However, when I replace the libaom.dll with the file from MSYS2 (there is also 3.6.1 version), AVIF works. I guess the problem is somehow related to the way how libaom is built or with the compiler.
Hmm, I have neither a crash in my VM on Windows 10 (AMD), nor on a real Windows 10 machine with Intel I5. Gilles added version 3.61 of libaom relatively recently. The question is, has the MXE stage been recompiled? Maik
yes it is, including all shared libs and the whole KF5 frameworks (eg KImageFormat). Gilles
I think we need to set the compile option "-DAOM_TARGET_CPU=generic". Otherwise, the compiling system's CPU is used. Maik
-DAOM_TARGET_CPU=generic completely disables assembler optimization. It will make the library very slow but It would be good to make that experiment to see if it helps. What about trying to avoid in-source build too?
Git commit c977031ec78cf2d914b5c163b3a8be9cf09e4000 by Gilles Caulier. Committed on 04/07/2023 at 03:44. Pushed by cgilles into branch 'master'. add new option to compile AOM under MinGW M +9 -0 project/bundles/3rdparty/ext_libaom/CMakeLists.txt https://invent.kde.org/graphics/digikam/-/commit/c977031ec78cf2d914b5c163b3a8be9cf09e4000
Today I tried digiKam-8.2.0-20230720T094929-Win64.exe and I am still getting the crash. I was curios to see if the https://invent.kde.org/graphics/digikam/-/commit/c977031ec78cf2d914b5c163b3a8be9cf09e4000 helped, but I have impression that libaom.dll is an older build from June so the change probably did not manifest yet?
Git commit ab3e2e5adb8d9e51cda6973e57828569dff21141 by Maik Qualmann. Committed on 23/07/2023 at 07:46. Pushed by mqualmann into branch 'master'. try new settings to compile libaom Related: bug 471269, bug 472508 M +2 -1 project/bundles/3rdparty/ext_libaom/CMakeLists.txt https://invent.kde.org/graphics/digikam/-/commit/ab3e2e5adb8d9e51cda6973e57828569dff21141
Fixed with 471269