https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #44 from griffiths_a...@icloud.com --- Done, and it gets over that initial ASSERT crash. But now it doesn't ASSERT crash where we want it to, as the timer is still < 20000ms. So we need a way of not crashing where we expect the query to take a long time. I reduced it to 14000, to maybe find a point at which the initial query succeeds, but subsequent ones fail if >= 14000. However, even the UI hang timers are still < 14000, at roughly 12000ms. As the times look fairly consistent, maybe it's the same query? So I went back to looking at the backtraces again by interrupting while there is the delay. 204 Thread 0x7fff307f8640 (LWP 1073656) "Thread (pooled)" 0x00007ffff3ce425a in __xstat64 () from /usr/lib/libc.so.6 (gdb) thread 204 [Switching to thread 204 (Thread 0x7fff307f8640 (LWP 1073656))] #0 0x00007ffff3ce425a in __xstat64 () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff3ce425a in __xstat64 () at /usr/lib/libc.so.6 #1 0x00007ffff3cb1e91 in __tzfile_read () at /usr/lib/libc.so.6 #2 0x00007ffff3cb1a3d in tzset_internal () at /usr/lib/libc.so.6 #3 0x00007ffff3cb1b4a in tzset () at /usr/lib/libc.so.6 #4 0x00007ffff3cb085d in timelocal () at /usr/lib/libc.so.6 #5 0x00007ffff4220ed0 in qMkTime(tm*) () at /usr/lib/libQt5Core.so.5 #6 0x00007ffff42f696e in () at /usr/lib/libQt5Core.so.5 #7 0x00007ffff42f7008 in () at /usr/lib/libQt5Core.so.5 #8 0x00007ffff42f8706 in QDateTime::toMSecsSinceEpoch() const () at /usr/lib/libQt5Core.so.5 #9 0x00007ffff42fbb11 in QDateTime::operator<(QDateTime const&) const () at /usr/lib/libQt5Core.so.5 #10 0x00007ffff706897d in qMapLessThanKey<QDateTime>(QDateTime const&, QDateTime const&) (key1=..., key2=...) at /usr/include/qt/QtCore/qmap.h:68 #11 0x00007ffff706d020 in QMapNode<QDateTime, int>::lowerBound(QDateTime const&) (this=0x7fff82fa70e0, akey=...) at /usr/include/qt/QtCore/qmap.h:152 #12 0x00007ffff70688d6 in QMapData<QDateTime, int>::findNode(QDateTime const&) const (this=0x7fff8000cb10, akey=...) at /usr/include/qt/QtCore/qmap.h:284 #13 0x00007ffff706472b in QMap<QDateTime, int>::find(QDateTime const&) (this=0x7fff307f7750, akey=...) at /usr/include/qt/QtCore/qmap.h:862 #14 0x00007ffff7056866 in Digikam::CoreDB::getAllCreationDatesAndNumberOfImages() const (this=0x555555ad7540) at /home/andyg/projects/digikam/core/libs/database/coredb/coredb.cpp:3268 #15 0x00007ffff70adfb2 in Digikam::DatesJob::run() (this=0x7fff80066fa0) at /home/andyg/projects/digikam/core/libs/database/dbjobs/dbjob.cpp:102 #16 0x00007ffff4230302 in () at /usr/lib/libQt5Core.so.5 #17 0x00007ffff422cf0f in () at /usr/lib/libQt5Core.so.5 #18 0x00007ffff3dc83e9 in start_thread () at /usr/lib/libpthread.so.0 #19 0x00007ffff3cf4293 in clone () at /usr/lib/libc.so.6 (gdb) Again we see Digikam::CoreDB::getAllCreationDatesAndNumberOfImages(), called from Digikam::DatesJob::run() Maybe this query is taking too long whenever it is run, regardless of where it's called in the code. -- You are receiving this mail because: You are watching all bug changes.