https://bugs.kde.org/show_bug.cgi?id=528175

--- Comment #6 from Fritz Hanke <[email protected]> ---
Hi Gilles,

Switching of Bitdefender does not change behaviour of digikam.

Attached the WinDbg File

I can't produce the debug console output nor debug console output nor
confirm the exact build because I can't read the selection menus, because
they are too dark.

Best regards
Fritz Hanke



Am Mo., 2. Nov. 2026 um 18:33 Uhr schrieb <[email protected]>:

> 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
> <https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorerright-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 reported the bug.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to