Application: digikam (5.5.0) Qt Version: 5.6.2 Frameworks Version: 5.32.0 Operating System: Linux 4.4.76-1-default x86_64 Distribution: "openSUSE Leap 42.3" -- Information about the crash: - What I was doing when the application crashed: Open digikam5 the first time. Select migration from version 4 (I was not sure if there is an old configuration on the system) After one hour of traying to mirgrate I press cancel. There was no old configuration on the system. -- Backtrace: Application: digiKam (digikam), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f08cbc13a00 (LWP 4065))] Thread 4 (Thread 0x7f087b3fc700 (LWP 4076)): #0 0x00007f08c37a30bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f08c78d569b in QWaitConditionPrivate::wait (time=18446744073709551615, this=0xe25b30) at thread/qwaitcondition_unix.cpp:136 #2 QWaitCondition::wait (this=this@entry=0xd631c0, mutex=mutex@entry=0xd631b8, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:208 #3 0x00007f08cb16f820 in Digikam::ScanController::run (this=0x7f08cba9cdc0 <_ZZN7Digikam12_GLOBAL__N_113Q_QGS_creator13innerFunctionEvE6holder>) at /usr/src/debug/digikam-5.5.0/core/libs/database/utils/scancontroller.cpp:677 #4 0x00007f08c78d4a29 in QThreadPrivate::start (arg=0x7f08cba9cdc0 <_ZZN7Digikam12_GLOBAL__N_113Q_QGS_creator13innerFunctionEvE6holder>) at thread/qthread_unix.cpp:365 #5 0x00007f08c379e744 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f08c6fcbaad in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f0884672700 (LWP 4069)): #0 0x00007f08c78cd44a in std::__atomic_base<QMutexData*>::compare_exchange_strong (__m2=std::memory_order_acquire, __m1=std::memory_order_acquire, __p2=0x1, __p1=@0x7f0884671940: 0x0, this=<optimized out>) at /usr/include/c++/4.8/bits/atomic_base.h:844 #1 std::atomic<QMutexData*>::compare_exchange_strong (__p2=0x1, __m=std::memory_order_acquire, __p1=@0x7f0884671940: 0x0, this=<optimized out>) at /usr/include/c++/4.8/atomic:445 #2 QAtomicOps<QMutexData*>::testAndSetAcquire<QMutexData*> (currentValue=<synthetic pointer>, newValue=0x1, expectedValue=0x0, _q_value=...) at ../../src/corelib/arch/qatomic_cxx11.h:158 #3 QBasicAtomicPointer<QMutexData>::testAndSetAcquire (currentValue=<synthetic pointer>: <optimized out>, newValue=0x1, expectedValue=0x0, this=this@entry=0xbb02a8) at ../../src/corelib/thread/qbasicatomic.h:276 #4 QBasicMutex::fastTryLock (current=<synthetic pointer>: <optimized out>, this=this@entry=0xbb02a8) at thread/qmutex.h:82 #5 QMutex::lock (this=this@entry=0xbb02a8) at thread/qmutex.cpp:219 #6 0x00007f08c7ae70d5 in QMutexLocker::QMutexLocker (m=0xbb02a8, this=<synthetic pointer>) at ../../src/corelib/thread/qmutex.h:128 #7 QThreadData::canWaitLocked (this=0xbb0280) at ../../src/corelib/thread/qthread_p.h:246 #8 postEventSourcePrepare (s=0x7f087c0012d0, timeout=0x7f08846719e4) at kernel/qeventdispatcher_glib.cpp:253 #9 0x00007f08be26195d in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0 #10 0x00007f08be262230 in ?? () from /usr/lib64/libglib-2.0.so.0 #11 0x00007f08be26242c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #12 0x00007f08c7ae71ab in QEventDispatcherGlib::processEvents (this=0x7f087c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:419 #13 0x00007f08c7a94bfb in QEventLoop::exec (this=this@entry=0x7f0884671ba0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:206 #14 0x00007f08c78cff5a in QThread::exec (this=<optimized out>) at thread/qthread.cpp:500 #15 0x00007f08c39ca295 in ?? () from /usr/lib64/libQt5DBus.so.5 #16 0x00007f08c78d4a29 in QThreadPrivate::start (arg=0x7f08c3c33ce0) at thread/qthread_unix.cpp:365 #17 0x00007f08c379e744 in start_thread () from /lib64/libpthread.so.0 #18 0x00007f08c6fcbaad in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f08854f9700 (LWP 4068)): #0 0x00007f08c37a30bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f0890996b4b in ?? () from /usr/lib64/dri/r600_dri.so #2 0x00007f08909968c7 in ?? () from /usr/lib64/dri/r600_dri.so #3 0x00007f08c379e744 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f08c6fcbaad in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f08cbc13a00 (LWP 4065)): [KCrash Handler] #6 Digikam::BdEngineBackend::status (this=0x0) at /usr/src/debug/digikam-5.5.0/core/libs/database/engine/dbenginebackend.cpp:798 #7 0x00007f08c8f645c4 in Digikam::BdEngineBackend::isOpen (this=<optimized out>) at /usr/src/debug/digikam-5.5.0/core/libs/database/engine/dbenginebackend.h:185 #8 Digikam::CoreDbAccess::CoreDbAccess (this=<optimized out>) at /usr/src/debug/digikam-5.5.0/core/libs/database/coredb/coredbaccess.cpp:119 #9 0x00007f08c8f01e17 in Digikam::CollectionScanner::databaseInitialScanDone () at /usr/src/debug/digikam-5.5.0/core/libs/database/collection/collectionscanner.cpp:1594 #10 0x00007f08cb1bb4cc in Digikam::DigikamApp::DigikamApp (this=0xe70000, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /usr/src/debug/digikam-5.5.0/core/app/main/digikamapp.cpp:172 #11 0x000000000040895f in main (argc=1, argv=<optimized out>) at /usr/src/debug/digikam-5.5.0/core/app/main/main.cpp:201 Reported using DrKonqi
With next 5.8.0 release Mysql support have been well improved and a lots of bugs fixed. Please test with pre release 5.8.0 bundles that we provide and give us a feedback https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle available here : https://files.kde.org/digikam/ Gilles Caulier
Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just released ? https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/
Maik, Marcel, I think this one is fixed with next 7.0.0. Can you confirm ? At least, i cannot reproduce here with my computer... Gilles
Gilles, wait with closing this bug. I recently also had a similar problem on the migration of the db type with my huge photo collection. Probably it is connected to this one. It took me several tries until migration worked. I'm trying to reproduce the error with debug information enabled.
Hi Marcel, Yes i would no close file too much quickly. This is why i start to post a remember comment to all entries with "crash", "major", "grave", and "critical" properties. This is what we call a "bugs-triage" (:-)) Gilles
Git commit e60e89cda0c483be18ac2a294c7a03511b710902 by Maik Qualmann. Committed on 09/07/2020 at 19:19. Pushed by mqualmann into branch 'master'. fix logic for stop processing in the for loop M +14 -11 core/libs/database/coredb/coredbcopymanager.cpp https://invent.kde.org/graphics/digikam/commit/e60e89cda0c483be18ac2a294c7a03511b710902
Git commit c2a0c8a42c852b7b3037cc7b81b39a94e490407b by Maik Qualmann. Committed on 09/07/2020 at 19:46. Pushed by mqualmann into branch 'master'. it is better not to skip the loop M +3 -3 core/libs/database/coredb/coredbcopymanager.cpp M +1 -1 core/libs/database/coredb/coredbcopymanager.h https://invent.kde.org/graphics/digikam/commit/c2a0c8a42c852b7b3037cc7b81b39a94e490407b
Git commit 91d7f791faf95873632e195da1241fb04d1cdfa2 by Maik Qualmann. Committed on 09/07/2020 at 20:24. Pushed by mqualmann into branch 'master'. use volatile for the stop flag M +1 -1 core/libs/database/coredb/coredbcopymanager.h https://invent.kde.org/graphics/digikam/commit/91d7f791faf95873632e195da1241fb04d1cdfa2
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
Johann, Stable digiKam 7.4.0 is published. Please check if problem is reproducible. https://www.digikam.org/download/ Thanks in advance
No feedback. not reproducible with 7.5.0. Closed