Bug 413750 - Akonadi crashes after terminating Kontact
Summary: Akonadi crashes after terminating Kontact
Status: REPORTED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 5.10.3
Platform: OpenSUSE Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-02 15:18 UTC by stakanov.s
Modified: 2019-11-02 15:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
backtrace of the original konqi popup (111.50 KB, text/plain)
2019-11-02 15:18 UTC, stakanov.s
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stakanov.s 2019-11-02 15:18:14 UTC
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?