Bug 304523 - nepomukservicestub consumes an ever growing amount of memory
Summary: nepomukservicestub consumes an ever growing amount of memory
Status: RESOLVED DUPLICATE of bug 304476
Alias: None
Product: nepomuk
Classification: Miscellaneous
Component: nepomukserver (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR critical
Target Milestone: ---
Assignee: Nepomuk Bugs Coordination
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-03 20:57 UTC by Craig Magina
Modified: 2012-08-06 09:56 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Magina 2012-08-03 20:57:24 UTC 
My computer started trashing as most applications were stuck waiting on IO due to all 8G of memory being consumed. I popped open System Activity and sorted via memory usage. It showed a nepomukservicestub using 5.5G of memory, so I killed it to gain control of my machine. It was immediately restarted and started its memory usage climb again. I watched it until it had consumed ~500M of memory when I killed it yet again. Of course, it was restarted and started to make the climb again. The CPU usage during this time is ~20% of a 6 core AMD 3.3GHz CPU. I disabled the nepomuk file indexing service, but that did not stop it. My virtuoso-t service seems to be fine and not growing out of control. My akonadi accounts consist of two google accounts, and an imap account.

I am running the recently pushed KDE 4.9.0 amd64 packages for Kubuntu 12.10.

Reproducible: Always
Comment 1 Craig Magina 2012-08-03 21:02:24 UTC 
I disabled the email indexer and the nepomukservicestub continues to grow. Disabling nepomuk does end it as would be expected, but re-enabling it brings it right back and it continues to grow.
Comment 2 Vishesh Handa 2012-08-03 23:18:12 UTC 
Please run $ ps aux | grep nepomuk, and report which nepomukservicestub is the culprit.

Thanks
Comment 3 Vishesh Handa 2012-08-06 09:56:22 UTC 

*** This bug has been marked as a duplicate of bug 304476 ***