Created attachment 123665 [details] backtrace of the original konqi popup Application: akonadiserver (5.10.3) Qt Version: 5.9.7 Frameworks Version: 5.55.0 Operating System: Linux 4.12.14-lp151.28.20-default x86_64 Distribution: "openSUSE Leap 15.1" -- Information about the crash: - What I was doing when the application crashed: The Kontact suite had, given a memory hole, consumed 8GB of Ram and nearly 4 Gb of Swap. In these conditions the only way to end the nearly unresponsive system and to normalize the memory, was to terminate with ctrl+alt+esc the Kontact suite. Normally when this happens akonadi does not crash (and normaly the memory hole of Kontact is not that catastrophic, thus, I decided to give this backtrace in the hope it may help to understand what actually happens there. - Unusual behavior I noticed: consumption of nearlz 12GB of Ram and SWAP during system idle. This seems to be connected to incomming mail that is then filtered. In these conditions the memory consumption (if system idle) starts. - Custom settings of the application: Large amounts of filters running on incomming mail. Three different income boxes (not an unified one to be clear). Clamav scan for viruses and spamd daemonized for spam. This is an upgrade of 15.0 to 15.1 Leap Opensuse and had the following attention after upgrading: having the baloo indexer crash as companion the searchdb was eliminated and did recreate after the update. So crashes of baloo do not take place any more for a while now. The akonadidatabase is regularly controlled with akonadictl fsck and sometimes with vaccum. There are several collections without RID. When running now the command akonadictl I get an astonishing result: mercurio@roadrunner:~> akonadictl start Akonadi is already running. mercurio@roadrunner:~> akonadictl fsck Akonadi Server is not running, check will not run Which means probably that there is the crashed instance still in memory?