https://bugs.kde.org/show_bug.cgi?id=528175
--- Comment #5 from [email protected] --- Hi Fritz, Thank you for testing the new installer and reporting back. So the fix in MR !452 is confirmed not to be the (complete) answer here. Let me explain what we need to move forward, because your dump unfortunately does not yet tell us where digiKam blocks. Why the dump is not usable as-is Your dump summary shows "Exception Code: not found". This means the dump was not captured on a crash the process was simply frozen. In that situation, the interesting information is not the module list, but the call stacks of all running threads: we need to see which thread is stuck, on which function, and which lock or database query it is waiting for. A module inventory alone does not contain that. What I need from you 1/ Thread stacks at the moment of the freeze. When digiKam hangs, please capture a new dump using: * Process Explorer: https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer right-click digikam.exe → Create Dump * Sysinternals procdump: procdump -h digikam.exe C:\temp\digikam_hang.dmp (the -h option triggers on a hang/unresponsive window). Even better: attach to the frozen process with a debugger ( WinDbg https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/ from the Microsoft Store) and export the stacks of all threads (~* kb in WinDbg). The stacks will show digiKam symbols and point directly at the guilty code path. 2/ The debug console output. Run digiKam from a console with debug enabled: Settings → Configure digiKam → Miscellaneous → Behavior → check "Show debug console". Reproduce the freeze and attach the full console log (not a screenshot uses text, please). Look especially at the last lines before the hang: with SQLite in WAL mode we want to see whether the process is stuck in a database transaction. Confirm the exact build. In the frozen digiKam, Help → About digiKam, and tell me the build date shown, so we are 100% sure the MR !452 patch is inside the binary you ran. A test to rule out a very common suspect on Windows Your dump shows that Bitdefender injects its hook DLLs (bdhkm64.dll, atcuf64.dll) into digikam.exe. Antivirus file-system hooks are a classic cause of exactly this symptom: short freezes of minutes, occurring randomly while digiKam scans/writes many small files (thumbnails, database pages) — which is precisely what happens while you assign names to faces on an initial 320k-photo load. Could you please try one session with: Bitdefender real-time protection temporarily disabled (or digiKam's install dir, your photo collection, and the database folder added to the exclusion list), then repeat the face-assignment work. If the freezes disappear or change character, that is a strong signal. If they persist unchanged, that is also useful information. What happens on our side Given the "hangs, then recovers, then hangs again" pattern with SQLite + WAL, I also want to check two things in the code: the frequency of commits in the face-assignment path with very large transactions, and possible lock contention between the face pipeline workers and the main thread. But without your thread stacks I would only be guessing at which of the two it is. Thanks in advance for the dumps and the console log. Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
