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.
