[Akonadi] [Bug 431773] New: Akonadi-Server and kmail crashes after moving mails from one folder to another

Klaus Mück bugzilla_noreply at kde.org
Mon Jan 18 10:58:02 GMT 2021 

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-bugs at kde.org
          Reporter: klaus at 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 at entry=0x7f4493f29c80,
flags=..., flags at entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f449d57f90a in QThread::exec (this=this at 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 at entry=0x7ffce8ad3890,
flags=..., flags at entry=...) at kernel/qeventloop.cpp:225
#5  0x00007f449d763780 in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1389
#6  0x000055ab1cba90f5 in AkApplicationBase::exec
(this=this at 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 the assignee for the bug.

More information about the Kdepim-bugs mailing list