[Akonadi] [Bug 413750] New: Akonadi crashes after terminating Kontact

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=413750

            Bug ID: 413750
           Summary: Akonadi crashes after terminating Kontact
           Product: Akonadi
           Version: 5.10.3
          Platform: openSUSE RPMs
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: server
          Assignee: kdepim-bugs at kde.org
          Reporter: stakanov at eclipso.eu
  Target Milestone: ---

Created attachment 123665
  --> https://bugs.kde.org/attachment.cgi?id=123665&action=edit
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 at roadrunner:~> akonadictl start
Akonadi is already running.
mercurio at roadrunner:~> akonadictl fsck
Akonadi Server is not running, check will not run

Which means probably that there is the crashed instance still in memory?

-- 
You are receiving this mail because:
You are the assignee for the bug.