Bug 276646 - crash while trying to switch database sqlite -> mysql
Summary: crash while trying to switch database sqlite -> mysql
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Database-Migration (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-27 21:33 UTC by Francesco Riosa
Modified: 2017-07-25 10:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Riosa 2011-06-27 21:33:31 UTC
Application: digikam (2.0.0-rc)
KDE Platform Version: 4.6.4 (4.6.4) (Compiled from sources)
Qt Version: 4.7.3
Operating System: Linux 2.6.39.1 x86_64
Distribution (Platform): Gentoo Packages

-- Information about the crash:
I was playing with a fresh database (operation done reported below) DK crashed while switching from sqlite to mysql.
Digikam was open but inactive for some time (I was doing other things) before trying the switch

--- phase 1 ---
	010- start a fresh digikam with first album data/testimages/a1
	020- rebuild all thumbnails
	030- rebuild fingerprints
	040+ create tag tree
	050- add album data/testimages/a2
	060+ add tags to images
	065- rotate icc-test-farbkreis.jpg 90° right
	070- rebuild all thumbnails
	080- rebuild fingerprints
	090+ dump data from sqlite database
	100- convert to mysql
	110+ dump data from mysql database

-- Backtrace:
Application: digiKam (digikam), signal: Segmentation fault
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
[Current thread is 1 (Thread 0x7f7e0ed67820 (LWP 28100))]

Thread 5 (Thread 0x7f7de96c6700 (LWP 28109)):
#0  pthread_cond_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f7e0659829f in wait (this=<value optimized out>, mutex=0x28766d8, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x28766d8, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x00000000005db4f6 in Digikam::ScanController::run (this=0x27a12b0) at /srv/git/digikam-sc/core/digikam/database/scancontroller.cpp:618
#4  0x00007f7e06597a8a in QThreadPrivate::start (arg=0x27a12b0) at thread/qthread_unix.cpp:320
#5  0x00007f7e06303cb0 in start_thread (arg=0x7f7de96c6700) at pthread_create.c:301
#6  0x00007f7e053320ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 4 (Thread 0x7f7de8ec5700 (LWP 28110)):
#0  0xffffffffff60017b in ?? ()
#1  0x00007f7de8ec4a30 in ?? ()
#2  0x00007fff95fff6e2 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x7f7de3fff700 (LWP 28112)):
#0  pthread_cond_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f7e0659829f in wait (this=<value optimized out>, mutex=0x2830b88, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x2830b88, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:160
#3  0x00007f7e0b639a13 in Digikam::ParkingThread::run (this=0x2830b70) at /srv/git/digikam-sc/core/libs/threads/threadmanager.cpp:119
#4  0x00007f7e06597a8a in QThreadPrivate::start (arg=0x2830b70) at thread/qthread_unix.cpp:320
#5  0x00007f7e06303cb0 in start_thread (arg=0x7f7de3fff700) at pthread_create.c:301
#6  0x00007f7e053320ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 2 (Thread 0x7f7dc1607700 (LWP 28284)):
#0  0x00007f7e06305b94 in __pthread_mutex_lock (mutex=0x79d2d88) at pthread_mutex_lock.c:61
#1  0x00007f7e04b7b9a3 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7e04b7c86d in ?? () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7e04b7cf09 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#4  0x00007f7e066bee46 in QEventDispatcherGlib::processEvents (this=0x78981c0, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:424
#5  0x00007f7e0668f562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#6  0x00007f7e0668f7a5 in QEventLoop::exec (this=0x7f7dc1606d20, flags=...) at kernel/qeventloop.cpp:201
#7  0x00007f7e06594db8 in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:492
#8  0x00007f7e0666f480 in QInotifyFileSystemWatcherEngine::run (this=0x7f30ff0) at io/qfilesystemwatcher_inotify.cpp:248
#9  0x00007f7e06597a8a in QThreadPrivate::start (arg=0x7f30ff0) at thread/qthread_unix.cpp:320
#10 0x00007f7e06303cb0 in start_thread (arg=0x7f7dc1607700) at pthread_create.c:301
#11 0x00007f7e053320ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 1 (Thread 0x7f7e0ed67820 (LWP 28100)):
[KCrash Handler]
#6  0x00007f7e066aa5d0 in cleanup (this=0x7602cc0, __in_chrg=<value optimized out>) at ../../src/corelib/tools/qscopedpointer.h:62
#7  ~QScopedPointer (this=0x7602cc0, __in_chrg=<value optimized out>) at ../../src/corelib/tools/qscopedpointer.h:100
#8  QObject::~QObject (this=0x7602cc0, __in_chrg=<value optimized out>) at kernel/qobject.cpp:818
#9  0x00007f7dee1bd499 in Oxygen::WidgetStateData::~WidgetStateData (this=0x7602cc0, __in_chrg=<value optimized out>) at /usr/src/debug/kde-base/kstyles-4.6.4/kstyles-4.6.4/kstyles/oxygen/animations/oxygenwidgetstatedata.h:51
#10 0x00007f7e066a6fe8 in QObject::event (this=0x7602cc0, e=<value optimized out>) at kernel/qobject.cpp:1200
#11 0x00007f7e072e2ea4 in QApplicationPrivate::notify_helper (this=0x268d550, receiver=0x7602cc0, e=0x8fc1ce0) at kernel/qapplication.cpp:4462
#12 0x00007f7e072e8351 in QApplication::notify (this=<value optimized out>, receiver=0x7602cc0, e=0x8fc1ce0) at kernel/qapplication.cpp:4341
#13 0x00007f7e08099bed in KApplication::notify (this=0x7fff95ec9790, receiver=0x7602cc0, event=0x8fc1ce0) at /usr/src/debug/kde-base/kdelibs-4.6.4-r1/kdelibs-4.6.4/kdeui/kernel/kapplication.cpp:311
#14 0x00007f7e06690a9b in QCoreApplication::notifyInternal (this=0x7fff95ec9790, receiver=0x7602cc0, event=0x8fc1ce0) at kernel/qcoreapplication.cpp:731
#15 0x00007f7e066949be in sendEvent (receiver=0x0, event_type=0, data=0x263e9f0) at kernel/qcoreapplication.h:215
#16 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x263e9f0) at kernel/qcoreapplication.cpp:1372
#17 0x00007f7e066bec53 in sendPostedEvents (s=<value optimized out>) at kernel/qcoreapplication.h:220
#18 postEventSourceDispatch (s=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:277
#19 0x00007f7e04b7c49d in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#20 0x00007f7e04b7cc78 in ?? () from /usr/lib64/libglib-2.0.so.0
#21 0x00007f7e04b7cf09 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#22 0x00007f7e066bedef in QEventDispatcherGlib::processEvents (this=0x263e5b0, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:422
#23 0x00007f7e0739403e in QGuiEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#24 0x00007f7e0668f562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#25 0x00007f7e0668f7a5 in QEventLoop::exec (this=0x7fff95ec95f0, flags=...) at kernel/qeventloop.cpp:201
#26 0x00007f7e06694cb9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008
#27 0x00000000006b4a37 in main (argc=1, argv=0x7fff95ec9e88) at /srv/git/digikam-sc/core/digikam/main/main.cpp:232

Possible duplicates by query: bug 276586, bug 276214, bug 272453, bug 271225, bug 269671.

Reported using DrKonqi
Comment 1 Francesco Riosa 2011-06-27 21:36:39 UTC
seem not too digikam related, looking also at the possible duplicate list, also at the re-opening of digikam the database was correctly set to mysql
Comment 2 caulier.gilles 2011-07-02 10:02:25 UTC
digiKam 2.0.0 RC is out. Please check if crash is reproducible with this version.

Thanks in advance

Gilles Caulier
Comment 3 Marcel Wiesweg 2011-07-11 15:26:41 UTC
I assume the crash is not reproducable, and occurred immediately while switching database engines?
Then it can be a digikam problem - the timing is very suspicious - but the backtrace does not help, even more if the crash is not reproducable. Only valgrind may show invalid memory operations.
Comment 4 Francesco Riosa 2011-07-12 23:43:04 UTC
I'm not able to reproduce it, if it will happen again I'll try a fix