[Akonadi] [Bug 431773] Akonadi-Server and kmail crashes after moving mails from one folder to another
https://bugs.kde.org/show_bug.cgi?id=431773 --- Comment #1 from Klaus Mück --- Another crash while moving mails Application: Akonadi Server (akonadiserver), signal: Segmentation fault [KCrash Handler] #4 _mm_crc32_u64 (__V=, __C=) at /usr/lib64/gcc/x86_64-suse-linux/7/include/smmintrin.h:848 #5 crc32 (ptr=0xfefd884d04e0, len=, h=) at tools/qhash.cpp:112 #6 0x7f7f5b563e74 in hash (seed=, len=, p=) at tools/qhash.cpp:223 #7 0x5620ad56d22b in QHash::findNode (this=this@entry=0x5620aeacf5b8, akey=..., ahp=ahp@entry=0x0) at /usr/include/qt5/QtCore/qhash.h:934 #8 0x5620ad56d89a in QHash::remove (this=this@entry=0x5620aeacf5b8, akey=...) at /usr/include/qt5/QtCore/qhash.h:806 #9 0x5620ad56a8ef in Akonadi::Server::ItemRetrievalManager::retrievalJobFinished (this=0x5620aeacf580, request=0x7f7ec42135f0, errorMsg=...) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/server/storage/itemretrievalmanager.cpp:179 #10 0x7f7f5b711f4f in QtPrivate::QSlotObjectBase::call (a=0x7f7f4ab75710, r=0x5620aeacf580, this=0x7f7f4c018b10) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394 #11 QMetaObject::activate (sender=sender@entry=0x7f7f400062c0, signalOffset=, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75710) at kernel/qobject.cpp:3784 #12 0x7f7f5b712547 in QMetaObject::activate (sender=sender@entry=0x7f7f400062c0, m=m@entry=0x5620ad85a1c0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75710) at kernel/qobject.cpp:3657 #13 0x5620ad5bb7e4 in Akonadi::Server::AbstractItemRetrievalJob::requestCompleted (this=this@entry=0x7f7f400062c0, _t1=, _t2=...) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/build/src/server/libakonadiserver_autogen/5XLNPBDXWK/moc_itemretrievaljob.cpp:135 #14 0x5620ad56e1e4 in Akonadi::Server::ItemRetrievalJob::callFinished (this=0x7f7f400062c0, watcher=) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/server/storage/itemretrievaljob.cpp:78 #15 0x7f7f5b711f4f in QtPrivate::QSlotObjectBase::call (a=0x7f7f4ab75900, r=0x7f7f400062c0, this=0x7f7f40003e20) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394 #16 QMetaObject::activate (sender=0x7f7f4c01b7e0, signalOffset=, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75900) at kernel/qobject.cpp:3784 #17 0x7f7f5b712547 in QMetaObject::activate (sender=, m=m@entry=0x7f7f5c06b5c0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75900) at kernel/qobject.cpp:3657 #18 0x7f7f5be4ed5f in QDBusPendingCallWatcher::finished (this=, _t1=) at .moc/moc_qdbuspendingcall.cpp:157 #19 0x7f7f5b7129e2 in QObject::event (this=0x7f7f4c01b7e0, e=) at kernel/qobject.cpp:1261 #20 0x7f7f5b6e2311 in doNotify (event=0x7f7f4c01fd50, receiver=0x7f7f4c01b7e0) at kernel/qcoreapplication.cpp:1178 #21 QCoreApplication::notify (event=, receiver=, this=) at kernel/qcoreapplication.cpp:1164 #22 QCoreApplication::notifyInternal2 (receiver=0x7f7f4c01b7e0, event=0x7f7f4c01fd50) at kernel/qcoreapplication.cpp:1088 #23 0x7f7f5b6e24fe in QCoreApplication::sendEvent (receiver=, event=event@entry=0x7f7f4c01fd50) at kernel/qcoreapplication.cpp:1476 #24 0x7f7f5b6e4ee7 in QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x5620aeb1e810) at kernel/qcoreapplication.cpp:1825 #25 0x7f7f5b6e5488 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1679 #26 0x7f7f5b73fd93 in postEventSourceDispatch (s=0x7f7f40004b70) at kernel/qeventdispatcher_glib.cpp:276 #27 0x7f7f572b04a4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #28 0x7f7f572b0840 in ?? () from /usr/lib64/libglib-2.0.so.0 #29 0x7f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #30 0x7f7f5b73f3af in QEventDispatcherGlib::processEvents (this=0x7f7f4b10, flags=...) at kernel/qeventdispatcher_glib.cpp:422 #31 0x7f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7f7f4ab75cb0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225 #32 0x7f7f5b50590a in QThread::exec (this=) at thread/qthread.cpp:531 #33 0x7f7f5b5070b2 in QThreadPrivate::start (arg=0x5620aeadd060) at thread/qthread_unix.cpp:361 #34 0x7f7f598ae4f9 in start_thread () from /lib64/libpthread.so.0 #35 0x7f7f5ab86fbf in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f7f4b377700 (LWP 9504) "CacheCleaner-Th"): #1 0x7f7f572afc53 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0 #2 0x7f7f572b06eb in ?? () from /usr/lib64/libglib-2.0.so.0 #3 0x7f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #4 0x7f7f5b73f3cb in QEventDispatcherGlib::processEvents (this=0x7f7f3c000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #5 0x7f7f5b6e057a in QEvent
[Akonadi] [Bug 431773] Akonadi-Server and kmail crashes after moving mails from one folder to another
https://bugs.kde.org/show_bug.cgi?id=431773 Klaus Mück changed: What|Removed |Added Version|unspecified |5.14.2 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 431773] New: Akonadi-Server and kmail crashes after moving mails from one folder to another
https://bugs.kde.org/show_bug.cgi?id=431773 Bug ID: 431773 Summary: Akonadi-Server and kmail crashes after moving mails from one folder to another Product: Akonadi Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: server Assignee: kdepim-b...@kde.org Reporter: kl...@muecknet.de Target Milestone: --- Application: akonadiserver (5.14.2 (20.04.2)) Qt Version: 5.12.7 Frameworks Version: 5.71.0 Operating System: Linux 5.3.18-lp152.60-default x86_64 Windowing system: X11 Distribution: openSUSE Leap 15.2 -- Information about the crash: - What I was doing when the application crashed: At first: I'm hosting nearly 35.000 mails. In the inbox there are nearly 15.000 mails. In summer I was updating from OpenSuse 12.x to Leap 15.2. I was starting kmail/akonadi from the scratch with postgresql. Problems: - Very slow when clicking a collection in kmail and in particular the inbox or other collections with many mails. Sometimes there is a message that it was not possible to find an item. - Often I have to start akonadi-server to see the mails. - Often there a are messages of unknown collections or other indexes. - Archiving of inbox breaks with the hint, there is a mail which is not possible to archive (... but which one?...). - akonadictl fsck reported many missing RIDs After a few days of intensive search in many communities, I found a hint how to solve these problems. - I stopped kmail and korganizer (no more akonadi-clients were activated). - I cleared all cashes in each collection with akonadiconsole (nearly 300 collections) manually ... this repaired a problem with archivng mails in the inbox folder. - Starting kmail and starting of recursive collection synchronization - There were some breaks of akonadiserver while synchronization, so I clicked manually in each collection ... nearly 300 ... - In some collections with finished synchronization by the recursive step above, were found additional mails ... ok ... strange ... - After finishing all these steps, I rebooted the system. It was only a step to reach a new fresh state of all. - Now I created 2 new collections under the inbox colection and I wanted to move older mails from the inbox to these collections for a speed up when accessing the inbox folder. - After three trials with aborting by kmail, I restarted akonadiserver. A part of the selected mails were moved. - Now I started a move again and now akonadiserver was crashing. A start of akonadiserver by clicking on the button in kmail crashed the akonadiserver again and now also kmail. Now I will reboot again after this report. That's my odysee with kmail and akonadi in the whole last week ... and I'm not really amused. Some technical questions: - Why are there two places for the mails? Inside the database and as file structure? I'm developing an application with sqlite with some million entries and references to image files in file system folders. We have to access these with real time conditions for eight channels. - I did also an import of the file structure created by kmail/akonadiserver with the import tool. What is the reason for creating the folder "new" inside an imported folder? What is the reason for saving the mails only inside the database cache and not in the file structure while doing the import step (of the own kmail structure) in difference to receiving mails, which are saved in the file structure? I do not know the reason for this design decision of the two places for the mails, but I think it is the reason for many problems, because of the need to synchronize both in particular with big mail storages. Where can I find a link, how to develop kmail and akonadi? The crash can be reproduced every time. -- Backtrace: Application: Akonadi Server (akonadiserver), signal: Aborted [KCrash Handler] #4 0x7f449cb3e520 in raise () from /lib64/libc.so.6 #5 0x7f449cb3fb01 in abort () from /lib64/libc.so.6 #6 0x7f449d17b016 in ?? () from /usr/lib64/libstdc++.so.6 #7 0x7f449d18688c in ?? () from /usr/lib64/libstdc++.so.6 #8 0x7f449d1868f7 in std::terminate() () from /usr/lib64/libstdc++.so.6 #9 0x7f449d55cf9b in qTerminate () at global/qglobal.cpp:3203 #10 0x7f449d58123b in QThreadPrivate::start (arg=0x55ab1e1b0670) at thread/qthread_unix.cpp:373 #11 0x7f449b9284f9 in start_thread () from /lib64/libpthread.so.0 #12 0x7f449cc00fbf in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f4493f2a700 (LWP 10804) "QDBusConnection"): #1 0x7f449932a7b9 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x7f449932a8cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x7f449d7b93cb in QEventDispatcherGlib::processEvents (this=0x7f448c000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #4
