Bug 431773 - Akonadi-Server and kmail crashes after moving mails from one folder to another
Summary: Akonadi-Server and kmail crashes after moving mails from one folder to another
Status: RESOLVED DUPLICATE of bug 423729
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 5.14.2
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2021-01-18 10:58 UTC by Klaus Mück
Modified: 2021-03-09 20:00 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Mück 2021-01-18 10:58:02 UTC
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  0x00007f449cb3e520 in raise () from /lib64/libc.so.6
#5  0x00007f449cb3fb01 in abort () from /lib64/libc.so.6
#6  0x00007f449d17b016 in ?? () from /usr/lib64/libstdc++.so.6
#7  0x00007f449d18688c in ?? () from /usr/lib64/libstdc++.so.6
#8  0x00007f449d1868f7 in std::terminate() () from /usr/lib64/libstdc++.so.6
#9  0x00007f449d55cf9b in qTerminate () at global/qglobal.cpp:3203
#10 0x00007f449d58123b in QThreadPrivate::start (arg=0x55ab1e1b0670) at thread/qthread_unix.cpp:373
#11 0x00007f449b9284f9 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f449cc00fbf in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f4493f2a700 (LWP 10804) "QDBusConnection"):
#1  0x00007f449932a7b9 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f449932a8cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f449d7b93cb in QEventDispatcherGlib::processEvents (this=0x7f448c000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4  0x00007f449d75a57a in QEventLoop::exec (this=this@entry=0x7f4493f29c80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f449d57f90a in QThread::exec (this=this@entry=0x7f449e0e7420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:531
#6  0x00007f449de6ee65 in QDBusConnectionManager::run (this=0x7f449e0e7420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:178
#7  0x00007f449d5810b2 in QThreadPrivate::start (arg=0x7f449e0e7420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:361
#8  0x00007f449b9284f9 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f449cc00fbf in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f449f009900 (LWP 10803) "akonadiserver"):
#1  0x00007f449932a7b9 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f449932a8cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f449d7b93af in QEventDispatcherGlib::processEvents (this=0x55ab1e188be0, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#4  0x00007f449d75a57a in QEventLoop::exec (this=this@entry=0x7ffce8ad3890, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f449d763780 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1389
#6  0x000055ab1cba90f5 in AkApplicationBase::exec (this=this@entry=0x7ffce8ad3990) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/shared/akapplication.cpp:124
#7  0x000055ab1c9f6700 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/server/main.cpp:79
[Inferior 1 (process 10803) detached]

The reporter indicates this bug may be a duplicate of or related to bug 430368.

Possible duplicates by query: bug 431764, bug 431077, bug 430846, bug 430790, bug 430722.

Reported using DrKonqi
Comment 1 Klaus Mück 2021-01-18 20:38:27 UTC
Another crash while moving mails

Application: Akonadi Server (akonadiserver), signal: Segmentation fault
[KCrash Handler]
#4  _mm_crc32_u64 (__V=<error reading variable: Cannot access memory at address 0xfefd884d04e0>, __C=<optimized out>) at /usr/lib64/gcc/x86_64-suse-linux/7/include/smmintrin.h:848
#5  crc32<QChar> (ptr=0xfefd884d04e0, len=<optimized out>, h=<optimized out>) at tools/qhash.cpp:112
#6  0x00007f7f5b563e74 in hash (seed=<optimized out>, len=<optimized out>, p=<optimized out>) at tools/qhash.cpp:223
#7  0x00005620ad56d22b in QHash<QString, Akonadi::Server::AbstractItemRetrievalJob*>::findNode (this=this@entry=0x5620aeacf5b8, akey=..., ahp=ahp@entry=0x0) at /usr/include/qt5/QtCore/qhash.h:934
#8  0x00005620ad56d89a in QHash<QString, Akonadi::Server::AbstractItemRetrievalJob*>::remove (this=this@entry=0x5620aeacf5b8, akey=...) at /usr/include/qt5/QtCore/qhash.h:806
#9  0x00005620ad56a8ef 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 0x00007f7f5b711f4f 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=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75710) at kernel/qobject.cpp:3784
#12 0x00007f7f5b712547 in QMetaObject::activate (sender=sender@entry=0x7f7f400062c0, m=m@entry=0x5620ad85a1c0 <Akonadi::Server::AbstractItemRetrievalJob::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75710) at kernel/qobject.cpp:3657
#13 0x00005620ad5bb7e4 in Akonadi::Server::AbstractItemRetrievalJob::requestCompleted (this=this@entry=0x7f7f400062c0, _t1=<optimized out>, _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 0x00005620ad56e1e4 in Akonadi::Server::ItemRetrievalJob::callFinished (this=0x7f7f400062c0, watcher=<optimized out>) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/server/storage/itemretrievaljob.cpp:78
#15 0x00007f7f5b711f4f 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=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75900) at kernel/qobject.cpp:3784
#17 0x00007f7f5b712547 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7f7f5c06b5c0 <QDBusPendingCallWatcher::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f7f4ab75900) at kernel/qobject.cpp:3657
#18 0x00007f7f5be4ed5f in QDBusPendingCallWatcher::finished (this=<optimized out>, _t1=<optimized out>) at .moc/moc_qdbuspendingcall.cpp:157
#19 0x00007f7f5b7129e2 in QObject::event (this=0x7f7f4c01b7e0, e=<optimized out>) at kernel/qobject.cpp:1261
#20 0x00007f7f5b6e2311 in doNotify (event=0x7f7f4c01fd50, receiver=0x7f7f4c01b7e0) at kernel/qcoreapplication.cpp:1178
#21 QCoreApplication::notify (event=<optimized out>, receiver=<optimized out>, this=<optimized out>) at kernel/qcoreapplication.cpp:1164
#22 QCoreApplication::notifyInternal2 (receiver=0x7f7f4c01b7e0, event=0x7f7f4c01fd50) at kernel/qcoreapplication.cpp:1088
#23 0x00007f7f5b6e24fe in QCoreApplication::sendEvent (receiver=<optimized out>, event=event@entry=0x7f7f4c01fd50) at kernel/qcoreapplication.cpp:1476
#24 0x00007f7f5b6e4ee7 in QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x5620aeb1e810) at kernel/qcoreapplication.cpp:1825
#25 0x00007f7f5b6e5488 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1679
#26 0x00007f7f5b73fd93 in postEventSourceDispatch (s=0x7f7f40004b70) at kernel/qeventdispatcher_glib.cpp:276
#27 0x00007f7f572b04a4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#28 0x00007f7f572b0840 in ?? () from /usr/lib64/libglib-2.0.so.0
#29 0x00007f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#30 0x00007f7f5b73f3af in QEventDispatcherGlib::processEvents (this=0x7f7f40000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#31 0x00007f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7f7f4ab75cb0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#32 0x00007f7f5b50590a in QThread::exec (this=<optimized out>) at thread/qthread.cpp:531
#33 0x00007f7f5b5070b2 in QThreadPrivate::start (arg=0x5620aeadd060) at thread/qthread_unix.cpp:361
#34 0x00007f7f598ae4f9 in start_thread () from /lib64/libpthread.so.0
#35 0x00007f7f5ab86fbf in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f7f4b377700 (LWP 9504) "CacheCleaner-Th"):
#1  0x00007f7f572afc53 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7f572b06eb in ?? () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#4  0x00007f7f5b73f3cb in QEventDispatcherGlib::processEvents (this=0x7f7f3c000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#5  0x00007f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7f7f4b376cb0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#6  0x00007f7f5b50590a in QThread::exec (this=<optimized out>) at thread/qthread.cpp:531
#7  0x00007f7f5b5070b2 in QThreadPrivate::start (arg=0x5620aeadb510) at thread/qthread_unix.cpp:361
#8  0x00007f7f598ae4f9 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f7f5ab86fbf in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f7f4bb78700 (LWP 9503) "NotificationMan"):
#1  0x00007f7f572b06eb in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7f5b73f3cb in QEventDispatcherGlib::processEvents (this=0x7f7f44000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4  0x00007f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7f7f4bb77cb0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f7f5b50590a in QThread::exec (this=<optimized out>) at thread/qthread.cpp:531
#6  0x00007f7f5b5070b2 in QThreadPrivate::start (arg=0x5620aeae2140) at thread/qthread_unix.cpp:361
#7  0x00007f7f598ae4f9 in start_thread () from /lib64/libpthread.so.0
#8  0x00007f7f5ab86fbf in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f7f51eb0700 (LWP 9500) "QDBusConnection"):
#1  0x00007f7f572b07b9 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7f5b73f3cb in QEventDispatcherGlib::processEvents (this=0x7f7f4c000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4  0x00007f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7f7f51eafc80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f7f5b50590a in QThread::exec (this=this@entry=0x7f7f5c06d420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:531
#6  0x00007f7f5bdf4e65 in QDBusConnectionManager::run (this=0x7f7f5c06d420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:178
#7  0x00007f7f5b5070b2 in QThreadPrivate::start (arg=0x7f7f5c06d420 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:361
#8  0x00007f7f598ae4f9 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f7f5ab86fbf in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f7f5cf8f900 (LWP 9499) "akonadiserver"):
#1  0x00007f7f572b07b9 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7f572b08cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7f5b73f3cb in QEventDispatcherGlib::processEvents (this=0x5620aeaadbe0, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4  0x00007f7f5b6e057a in QEventLoop::exec (this=this@entry=0x7fff7986dd80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f7f5b6e9780 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1389
#6  0x00005620ad5e20f5 in AkApplicationBase::exec (this=this@entry=0x7fff7986de80) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/shared/akapplication.cpp:124
#7  0x00005620ad42f700 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/akonadi-server-20.04.2-lp152.2.3.1.x86_64/src/server/main.cpp:79
[Inferior 1 (process 9499) detached]
Comment 2 Christophe Marin 2021-03-09 20:00:42 UTC

*** This bug has been marked as a duplicate of bug 423729 ***