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 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 -- You are receiving this mail because: You are watching all bug changes.