Created attachment 134351 [details] Digikam stack trace for Assert fail in similaritydbaccess.cpp SUMMARY Starting digikam with tens of thousands of images, during the initial "Sannind Collections, Please wait" phase, after about 10,000 images (many of which have both a JPG and a NEF), it crashes: ASSERT: "d" in file /usr/obj/ports/digikam-7.1.0/digikam-7.1.0/core/libs/database/similaritydb/similaritydbaccess.cpp, line 105 Abort trap (core dumped) STEPS TO REPRODUCE 1. Run digikam 2. Wait 3. Examine core dump OBSERVED RESULT Core dump EXPECTED RESULT Digikam should show up with all the images SOFTWARE/OS VERSIONS OpenBSD 6.8 Current Linux/KDE Plasma: 7.1.0 (available in About System) KDE Plasma Version: 5.76.0 KDE Frameworks Version: 5.76.0 Qt Version: 5.13.2 ADDITIONAL INFORMATION Others claim it works for them in a similar environment. I tried moving aside the last directory it reported, so it occurs in a later directory. A very quick look at the code shows that parameter 'd', which is supposed to be the database, is passed as null, suggesting resource exhaustion, but that does not seem to be the case here: $ ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 4194304 stack(kbytes) 4096 lockedmem(kbytes) 5383068 memory(kbytes) 16137044 nofiles(descriptors) 6144 processes 256 $ ps axl|sed q UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND $ while : > do ps axl|grep digikam > sleep 30 > done 1000 60845 60215 0 2 0 62352 125580 poll S+ p1 0:27.77 digikam 1000 96539 55460 0 28 0 864 8 - R+p/0 p2 0:00.00 grep digikam (ksh) 1000 60845 60215 1 2 0 62848 126004 poll R+/2 p1 0:45.87 digikam 1000 70894 55460 0 -6 0 280 1344 piperd S+p p2 0:00.01 grep digikam 1000 60845 60215 1 2 0 63432 126744 poll R+/0 p1 1:05.09 digikam 1000 7566 55460 0 -6 0 292 1376 piperd S+p p2 0:00.01 grep digikam 1000 60845 60215 0 2 0 64016 127276 poll R+/0 p1 1:24.16 digikam 1000 86037 55460 0 -6 0 292 1368 piperd S+p p2 0:00.01 grep digikam 1000 60845 60215 0 2 0 64396 127744 poll R+/0 p1 1:44.78 digikam 1000 60845 60215 0 2 0 64728 128156 poll S+ p1 2:02.81 digikam 1000 79126 55460 0 28 0 112 372 - R+/2 p2 0:00.00 grep digikam 1000 60845 60215 0 2 0 65148 128644 poll S+ p1 2:21.85 digikam 1000 92159 55460 0 -6 0 284 1348 piperd S+p p2 0:00.01 grep digikam 1000 67944 55460 0 -6 0 288 1360 piperd S+p p2 0:00.01 grep digikam Stacktrace attached.
Did you update a very old digiKam database? Because an update from V4 to V7 was carried out. An error may have occurred while creating the similarity database. Activate the debug output and give us the log from the terminal as described here: https://www.digikam.org/contribute/ Maik
This problem can only occur if the similarity database has not been initialized. Which cannot actually not occur because the pointer is always assigned a value. I suspect there was a crash while scanning and parts of digiKam were already in delete mode. The scanner thread then encountered zo the pointer that had already been deleted. So we need a better backtrace, don't forget "bt" next time. Maik
Thank you!!! I feel like a goof. Moving all the .db files out of ~/Pictures lets it start up, and it's busy doing what I presume is making tens of thousands of thumbnails in the background. If you think it is worthwhile, I can try to switch the new db files out for the old and give you debug log and bt. Thanks Ian On 12/27/20 10:26 AM, Maik Qualmann wrote: > https://bugs.kde.org/show_bug.cgi?id=430858 > > Maik Qualmann <metzpinguin@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |metzpinguin@gmail.com > > --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- > Did you update a very old digiKam database? Because an update from V4 to V7 was > carried out. An error may have occurred while creating the similarity database. > Activate the debug output and give us the log from the terminal as described > here: https://www.digikam.org/contribute/ > > Maik >
As I said, the crash can no longer be reproduced exactly. the QApplication ist crashed and exits, the databases were cleaned up, but the ScanController thread did not stop. It can also hit the core database. We would have to use the debug output to determine which file was last scanned and triggered the crash. Maik
digiKam 7.2.0 official release is published with more than 360 files closed from bugzilla: https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/ Can you reproduce the dysfunction with this version ? Thanks in advance for your feedback Gilles Caulier
Ian, Stable digiKam 7.4.0 is published. Please check if problem is reproducible. https://www.digikam.org/download/ Thanks in advance Gilles Caulier
Ian, Please review the last comment from me and Maik about this entry. We needs a fresh feedback, else we will close the file as well... Best regards Gilles Caulier
Please close; as I mentioned I can no longer reproduce the problem.
not reproducible with 7.5.0. Closed
Git commit 7c7a6406839ed9c233d14bf935b642cb96af6425 by Maik Qualmann. Committed on 27/10/2023 at 22:23. Pushed by mqualmann into branch 'master'. fix race condition with uninitialized similarity database Related: bug 476157 FIXED-IN: 8.2.0 M +1 -1 NEWS M +5 -5 core/libs/album/manager/albummanager_database.cpp M +2 -2 core/libs/database/utils/scan/scancontroller.cpp M +9 -0 core/libs/database/utils/scan/scancontroller.h M +11 -0 core/libs/database/utils/scan/scancontroller_start.cpp https://invent.kde.org/graphics/digikam/-/commit/7c7a6406839ed9c233d14bf935b642cb96af6425