Akonadi EWS crashes once in a while: $ equery b /usr/bin/akonadi_ews_resource * Searching for /usr/bin/akonadi_ews_resource ... kde-apps/kdepim-runtime-17.12.1 (/usr/bin/akonadi_ews_resource) $ coredumpctl dump 3018 PID: 3018 (akonadi_ews_res) UID: 500 (kakra) GID: 500 (kakra) Signal: 11 (SEGV) Timestamp: Sat 2018-02-10 12:37:14 CET (24h ago) Command Line: /usr/bin/akonadi_ews_resource --identifier akonadi_ews_resource_0 Executable: /usr/bin/akonadi_ews_resource Control Group: /user.slice/user-500.slice/session-c1.scope Unit: session-c1.scope Slice: user-500.slice Session: c1 Owner UID: 500 (kakra) Boot ID: 6062cfc5bd404679bf9f3a0ef42ce52c Machine ID: 121b87ca633e8ac0016656680000001b Hostname: jupiter Storage: /var/lib/systemd/coredump/core.akonadi_ews_res.500.6062cfc5bd404679bf9f3a0ef42ce52c.3018.1518262634000000.lz4 Message: Process 3018 (akonadi_ews_res) of user 500 dumped core. Stack trace of thread 3018: #0 0x00007f4f39a9489b _ZNK9QHashNodeI7QStringP19KConfigSkeletonItemE8same_keyEjRKS0_ (libKF5ConfigCore.so.5) #1 0x00007f4f39a948e9 _ZNK19KCoreConfigSkeleton11isImmutableERK7QString (libKF5ConfigCore.so.5) #2 0x000055af9181ba7d _ZN15EwsSettingsBase22setEventSubscriptionIdERK7QString (akonadi_ews_resource) #3 0x000055af9181e297 _ZN22EwsSubscriptionManagerD4Ev (akonadi_ews_resource) #4 0x000055af9180ddd8 _ZN21QScopedPointerDeleterI22EwsSubscriptionManagerE7cleanupEPS0_ (akonadi_ews_resource) #5 0x000055af9180de49 _ZN11EwsResourceD0Ev (akonadi_ews_resource) #6 0x00007f4f3c240b9e _ZN7Akonadi12ResourceBase4initEPS0_ (libKF5AkonadiAgentBase.so.5) #7 0x000055af918172a7 _ZN7Akonadi12ResourceBase4initI11EwsResourceEEiiPPc (akonadi_ews_resource) #8 0x00007f4f374a25f1 __libc_start_main (libc.so.6) #9 0x000055af917bb16a _start (akonadi_ews_resource) Stack trace of thread 3041: #0 0x00007f4f3757018d poll (libc.so.6) #1 0x00007f4f34ed18d0 poll (libxcb.so.1) #2 0x00007f4f34ed4229 xcb_wait_for_event (libxcb.so.1) #3 0x00007f4f2b965f39 _ZN15QXcbEventReader3runEv (libQt5XcbQpa.so.5) #4 0x00007f4f37ef9e39 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5) #5 0x00007f4f343658b7 start_thread (libpthread.so.0) #6 0x00007f4f3757b52f __clone (libc.so.6) Stack trace of thread 3063: #0 0x00007f4f3757018d poll (libc.so.6) #1 0x00007f4f322accc6 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f4f322acddc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f4f38128f7f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #4 0x00007f4f380cffda _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #5 0x00007f4f37ef4e73 _ZN7QThread4execEv (libQt5Core.so.5) #6 0x00007f4f397d1585 _ZN22QDBusConnectionManager3runEv (libQt5DBus.so.5) #7 0x00007f4f37ef9e39 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5) #8 0x00007f4f343658b7 start_thread (libpthread.so.0) #9 0x00007f4f3757b52f __clone (libc.so.6)
The crash seems to be in KF5: [ 166.432091] akonadi_ews_res[3018]: segfault at 8 ip 00007f4f39a9489b sp 00007fff069ee290 error 4 in libKF5ConfigCore.so.5.42.0[7f4f39a51000+61000] $ equery b /usr/lib64/libKF5ConfigCore.so.5 * Searching for /usr/lib64/libKF5ConfigCore.so.5 ... kde-frameworks/kconfig-5.42.0 (/usr/lib64/libKF5ConfigCore.so.5.42.0) kde-frameworks/kconfig-5.42.0 (/usr/lib64/libKF5ConfigCore.so.5 -> libKF5ConfigCore.so.5.42.0)
Hi Kai. Sorry that you did not receive a reply to this bug so far. Does the crash still happen with KDEPIM/Akonadi 18.12 and recent KDE Frameworks?
I removed Akonadi completely because it started to accumulate gigabytes of RAM over time since one of the last updates (the processes growing to 9 GB of RAM usage). And there's even not a sane mail client to actually use Akonadi's potential. KMail is still very unstable, slow, and buggy. So I moved away and I am currently using Mailspring instead. I may try the KDE PIM suite some day in the future again because I'm missing the calendar feature. The next thing to go away is probably baloo because it got slow. Its processes tend to grow to 3-4 GB of RAM usage and eat a lot of IO performance during that process, the system feels very laggy until I kill the processes. Also, it started to re-index all my files on every reboot. In both cases I tried recreating the databases (Akonadi and Baloo) from scratch but it didn't solve the problem. I'm feeling a bit sad about this because usually I enjoyed the good integration of the KDE components into the complete desktop. But if it makes a quite potent system to vastly slow down for extended periods of time, I have no other choice. I needed to remove all PIM components completely to get back a snappy and stable KDE desktop. :-( I wonder why this hit me lately: I've run with both Baloo and Akonadi for years and never experienced the problems one could read about in hundreds of forums, namely that those services slow done people's systems. Now it happened to me, too, and the impact is really very big. Baloo and Akonadi really need some love, and I wish I could be part of this by contributing help with identifying and fixing bugs. But the negative impacts it had on my productivity were just too big. I'm sorry.
Hello Kai. Thank you for the information. I am closing this bug cause as you do not use KDEPIM/Akonadi anymore, you would not provide any further information – for example whether this segfault still exists. If anyone finds this segfault again, please open a new bug. Thank you. As for Baloo: That is a different topic, but this bug tracker is not the place to discuss it. However, in case you can confirm [frameworks-baloo] [Bug 404057] New: Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing please comment there, so I can set it to CONFIRMED.