Bug 304476 - nepomukfilewatch memleak
Summary: nepomukfilewatch memleak
Status: RESOLVED FIXED
Alias: None
Product: nepomuk
Classification: Unclassified
Component: filewatch (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Nepomuk Bugs Coordination
URL:
Keywords:
: 304523 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-08-03 00:05 UTC by Dennis Schridde
Modified: 2012-08-08 14:40 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Schridde 2012-08-03 00:05:51 UTC
After about 5h nepomukfilewatch had allocated about 8GiB of memory. It allocates about 0.5MiB/s and runs at 100% CPU. The issue comes right back after killing nepomukfilewatch - the new process will start allocating memory (and eating CPU time) right away.

Nepomuk file indexing is disabled, as is email indexing. If you cannot reproduce this, please provide me with instructions on how to debug this.

I am using KDE 4.9.0. See also bug #226676 against KDE 4.4.

Reproducible: Always




Portage 2.2.0_alpha120 (default/linux/amd64/10.0/desktop/kde, gcc-4.7.1, glibc-2.15-r2, 3.5.0-gentoo x86_64)
=================================================================
System uname: Linux-3.5.0-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-gentoo-2.1
Timestamp of tree: Thu, 02 Aug 2012 23:15:01 +0000
distcc 3.2rc1 x86_64-pc-linux-gnu [disabled]
app-shells/bash:          4.2_p37
dev-java/java-config:     2.1.12
dev-lang/python:          2.7.3-r2, 3.2.3-r1
dev-util/cmake:           2.8.8-r3
dev-util/pkgconfig:       0.27
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.10.5
sys-apps/sandbox:         2.6
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.6, 1.12.2
sys-devel/binutils:       2.22.90
sys-devel/gcc:            4.6.3, 4.7.1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 3.5 (virtual/os-headers)
sys-libs/glibc:           2.15-r2
Comment 1 Vishesh Handa 2012-08-03 06:46:46 UTC
Thanks for the bug report.

Were you moving a number of files or directories during that time? Or were a lot of files being created or deleted?

Also, if possible please switch off the filewatch service via - 
$ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown

and then run it again via $ nepomukservicestub nepomukfilewatch. Please attach the entire debug output. Also make sure you have nepomuk debug output enabled via kdebugdialog.
Comment 2 Dennis Schridde 2012-08-03 08:54:59 UTC
(In reply to comment #1)
> Were you moving a number of files or directories during that time? Or were a
> lot of files being created or deleted?
No, doubtful. The system was idling the whole time. It even happens right now, while I have not more than this browser window open…

> Also, if possible please switch off the filewatch service via - 
> $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown
> 
> and then run it again via $ nepomukservicestub nepomukfilewatch. Please
> attach the entire debug output. Also make sure you have nepomuk debug output
> enabled via kdebugdialog.
Will do that in a couple of days, when I have the time. (Same goes for the isql-vt->status() output you asked me for in the other report.)
Comment 3 Vishesh Handa 2012-08-03 11:10:54 UTC
Alright. Let me know.
Comment 4 Vishesh Handa 2012-08-06 09:56:22 UTC
*** Bug 304523 has been marked as a duplicate of this bug. ***
Comment 5 Vishesh Handa 2012-08-06 10:05:44 UTC
Please could you guys test the following patch - https://git.reviewboard.kde.org/r/105892/

It should fix the issue, but I'd like a confirmation before committing it. Specially since I cannot reproduce the issue.
Comment 6 Dennis Schridde 2012-08-06 15:13:09 UTC
(In reply to comment #5)
> Please could you guys test the following patch
I applied your patch and the memleak appears to be gone (htop shows no increase in memory usage and no process running at 100% cputime).

Below is the output of nepomukfilewatch AFTER applying the patch:
nepomukfilewatch(25714)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-USER/ksycoca4"
nepomukfilewatch(25714)/nepomuk (library) {anonymous}::GlobalModelContainer::init: Connecting to local socket "/tmp/.private/dschridde/ksocket-USER/nepomuk-socket"
nepomukfilewatch(25714)/nepomuk (filewatch service) Nepomuk2::FileWatch::watchFolder: "/home/USER"
nepomukfilewatch(25714)/nepomuk (filewatch service) KInotify::addWatch: "/home/USER"
nepomukfilewatch(25714)/nepomuk (filewatch service) KInotify::Private::open:
nepomukfilewatch(25714)/nepomuk (filewatch service) KInotify::Private::open: Successfully opened connection to inotify: 14
nepomukfilewatch(25714)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Searching for invalid local file entries
nepomukfilewatch(25714)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Done searching for invalid local file entries
nepomukfilewatch(25714)/nepomuk (filewatch service) KInotify::Private::_k_addWatches: Done adding watches
Comment 7 Vishesh Handa 2012-08-06 15:30:17 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Please could you guys test the following patch
> I applied your patch and the memleak appears to be gone (htop shows no
> increase in memory usage and no process running at 100% cputime).
> 

Thanks a lot. I'll commit the patch tomorrow. It'll be there in 4.9.1

I wish this had been caught during the beta or RC1 testing.
Comment 8 Dennis Schridde 2012-08-06 20:43:52 UTC
Thanks for your quick response! I pushed this into Gentoo as kde-base/nepomuk-core-4.9.1-r1 [1] (kde-overlay, soon to arrive in mainline, I hope).

[1] https://bugs.gentoo.org/show_bug.cgi?id=430226
Comment 9 Vishesh Handa 2012-08-07 05:58:38 UTC
Git commit a81f05034baef438eacd346fcbc97dd818a0b5bf by Vishesh Handa.
Committed on 06/08/2012 at 11:31.
Pushed by vhanda into branch 'KDE/4.9'.

kinotify: Do not store the paths to be added

kinotify used a QQueue<QByteArray> to store all the directories which
need to be added. Since we use QDirIterator, each path is presented as a
QString which is then encoded to its QByteArray (QFile::encodeName).
This results in *large* chunks of memory being allocated, and then
slowly being deallocated.

Instead, we now use a QDirIterator, and do not store all the directories
which need to be added, we simply iterate over them. This way we do not
allocate large amounts of memory.

There is a large performance improvement as well. On my system, with
38829 directories, adding all the watches now takes only about 10 seconds,
instead of about 65.

Patch possible due to massif output provided by Jure Repinc <jlp@holodeck1.com>.
Thanks a lot.

tldr: Use DFS instead of BFS -> Less memory consumption
REVIEW: 105892
DIGEST: Fix massive memory leak in Nepomuk File Monitoring Service

M  +14   -24   services/filewatch/kinotify.cpp

http://commits.kde.org/nepomuk-core/a81f05034baef438eacd346fcbc97dd818a0b5bf
Comment 10 Vishesh Handa 2012-08-08 14:40:52 UTC
Btw, in case someone is backporting this. Please either use the patch on the review request on the combination of the commit above and this one -

commit 7322b28f46969adb721daecf5a7fb67b8e0c6ae4
Author: Vishesh Handa <me@vhanda.in>
Date:   Wed Aug 8 14:33:02 2012 +0530

    Break out of kinotify's _k_addWatches loop
    
    Didn't test the patch out after making a super trivial change in the
    review request. Stupid Stupid me!

diff --git a/services/filewatch/kinotify.cpp b/services/filewatch/kinotify.cpp
index 47eb8ed..509abff 100644
--- a/services/filewatch/kinotify.cpp
+++ b/services/filewatch/kinotify.cpp
@@ -152,6 +152,7 @@ public:
             }
             else {
                 delete dirIterators.dequeue();
+                break;
             }
         }