Created attachment 112457 [details] Full backtrace Unfortunately, I don't have the time to investigate the problem myself - maybe the trace already explains the cause: I do face detection discarding unconfirmed results from the peoples right sidebar on a local collection of ~50k items with an internal mysql db. The scan aborts with a segmentation fault (see attached full bt). Scanning the directory, where the exception occurred, does not reproduce the issue. Scanning the entire collection again, does reproduce the issue, but neither after the same time nor at the same file. I unfortunately just overwrote the log file by restarting digikam (I am relying heavily at the moment :) ) without creating a copy first, but I could recreate it if necessary (scan until fault takes time though). Used appimage: digikam-6.0.0-git-20180430T091500-x86-64.appimage System: Debian buster
Simon, I insert your bug as a duplicate. The bug reports look very identical. I suppose here a problem with QHash, even if the patch is not the case in the crash of Gilles is the solution. I'm going to patch git/master for the test tonight, Gilles will then create a new AppImage and you can then test it on your image collection. Maik *** This bug has been marked as a duplicate of bug 392134 ***
yes, sure for the AppImage. Just ask and i just to press a button to re-generate all bundles (:=)))... Gilles
Yes, it seems very likely to be the same thing - thanks for finding that for me. I looked for mentioning of detect instead of scan. I'll try again once the new AppImage is out and report back in the other issue. Thank you very much for all your work!
Ok, Gilles, press the button (:=)) Maik
The button in pressed. Compilation is in the way. Maik : i see your commit https://commits.kde.org/digikam/fe647204d0bfcd30946f27ebd7bb822a1f6e1cf1 It touch threadimageio API. Do you see that we have 2 clang reports in this API, when color management is enabled : https://www.digikam.org/reports/clang/report-93acd3.html#EndPath https://www.digikam.org/reports/clang/report-55fdb2.html#EndPath Both are the same in fact about to use a possible NULL ICCProfile pointer. At least we test if null, so potentially, the condition can appear. Simon, Do you use CM on your computer ? Gilles
Simon, Linux AppImage 64 bits will be online in few minutes (403Mb): https://files.kde.org/digikam/ Gilles
Git commit f2f48773e6204c4a3643a6f9a5f98c09120c0528 by Maik Qualmann. Committed on 07/05/2018 at 17:18. Pushed by mqualmann into branch 'master'. Clang static analyzer fix about null C++ object pointer called M +7 -2 core/libs/threadimageio/thumbnailcreator.cpp https://commits.kde.org/digikam/f2f48773e6204c4a3643a6f9a5f98c09120c0528
I fixed the reported issue, but this is not the cause. In the Loading Cache we have a QHash list, in which the Loading Tasks register and unsubscribe to receive messages. This is programmed in a complex way. The idea is that a task can communicate what it is loading so that another task does not load the same, very well done. The problem is that an already dead task still receives a message. There are only 2 possibilities, either it actually creates a QHash collision or a timing problem and a finished task has not yet removed from QHash list. Maik
Not reproducible with last 6.1.0 pre-release AppImage bundle : https://files.kde.org/digikam/ Gilles Caulier