Created attachment 188428 [details] latest stable 8.8.0 backtrace SUMMARY Digikam crashes when trying to cancel a long running FindDuplicates. STEPS TO REPRODUCE 1. Start a FindDuplicate on an album, using all albums as reference (in order to have long running FindDuplicate) 2. Try to 'Cancel this operation' OBSERVED RESULT digikam crashes EXPECTED RESULT Operation is interupted without crash SOFTWARE/OS VERSIONS macOS Sequoia 15.6.1 ADDITIONAL INFORMATION backtrace attached for latest stable 8.8.0. Tested on weekly release digiKam-9.0.0-20260111T200122-Qt6-MacOS-arm64-debug.pkg and still crash with same BT.
Created attachment 188429 [details] weekly release backtrace
Git commit e1ce41605329e02dbc6cf1597882668393b668bf by Maik Qualmann. Committed on 12/01/2026 at 11:47. Pushed by mqualmann into branch 'master'. wait for all jobs finish at QThreadPool at cancel action M +4 -4 core/libs/threads/actionthreadbase.cpp https://invent.kde.org/graphics/digikam/-/commit/e1ce41605329e02dbc6cf1597882668393b668bf
A new macOS pre-release digiKam-9.0.0 is available; is the crash, caused by canceling the duplicates search, still reproducible? Maik
Just tried now with digiKam-9.0.0-20260113T040111-Qt6-MacOS-arm64-debug and it does not crash anymore: from user point of view, this bug is resolved. Looking at detailed debug statements, the "Cancel" line is now followed by a "Finish" line with few duplicate checks in between... 2026-01-14 01:42:16.990352+0100 digikam[7691:334973] [digikam.general] Cancel Main Thread 2026-01-14 01:42:16.991805+0100 digikam[7691:341578] [digikam.database] Duplicates with id and score: 2026-01-14 01:42:16.991813+0100 digikam[7691:341578] [digikam.database] 40370 "100%" 2026-01-14 01:42:16.991816+0100 digikam[7691:341578] [digikam.database] 51484 "100%" 2026-01-14 01:42:17.035078+0100 digikam[7691:341583] [digikam.database] Duplicates with id and score: 2026-01-14 01:42:17.035098+0100 digikam[7691:341583] [digikam.database] 14231 "100%" 2026-01-14 01:42:17.035102+0100 digikam[7691:341583] [digikam.database] 14232 "100%" 2026-01-14 01:42:17.036891+0100 digikam[7691:341586] [digikam.database] Duplicates with id and score: 2026-01-14 01:42:17.036899+0100 digikam[7691:341586] [digikam.database] 11784 "100%" 2026-01-14 01:42:17.036902+0100 digikam[7691:341586] [digikam.database] 11785 "100%" 2026-01-14 01:42:17.036905+0100 digikam[7691:341586] [digikam.database] 11786 "100%" 2026-01-14 01:42:17.043806+0100 digikam[7691:341582] [digikam.database] Duplicates with id and score: 2026-01-14 01:42:17.043818+0100 digikam[7691:341582] [digikam.database] 42773 "100%" 2026-01-14 01:42:17.043822+0100 digikam[7691:341582] [digikam.database] 52699 "100%" 2026-01-14 01:42:17.049983+0100 digikam[7691:341584] [digikam.database] Duplicates with id and score: 2026-01-14 01:42:17.049989+0100 digikam[7691:341584] [digikam.database] 6213 "100%" 2026-01-14 01:42:17.049993+0100 digikam[7691:341584] [digikam.database] 6214 "100%" 2026-01-14 01:42:17.076815+0100 digikam[7691:334973] [digikam.general] Finish Main Thread
The behavior in the debug log is correct; the individual tasks complete their current job until they terminate when a new job is requested after "cancel". Especially with time-intensive tasks, it can take a while for the task to "finish"; we are waiting for this to happen. Maik