Launchpad has imported 24 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=226676.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-02-13T14:33:53+00:00 Phull wrote: Version: unknown (using 4.4.00 (KDE 4.4.0) "release 222", KDE:KDE4:Factory:Desktop / openSUSE_11.2) Compiler: gcc OS: Linux (x86_64) release 2.6.31.12-0.1-desktop During initial indexing of my home directory, nepomukservicestub nepomukfilewatch grows to well over 2GByte of memory, rendering the system unusable due to constant swapping. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/0 ------------------------------------------------------------------------ On 2010-02-18T11:50:27+00:00 Ub71a5bwcb7ku-martin-b69y0hv8hgzde wrote: I can confirm that this service is eating a lot of memory during indexing. At this time I can't say if this returns to normal if the indexing task is finished. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/1 ------------------------------------------------------------------------ On 2010-03-15T14:21:19+00:00 Paul Leopardi wrote: Can also confirm: # ps -e -o args -o vsz | grep nepomuk kdeinit4: nepomukserver [kd 315304 /usr/bin/nepomukservicestub 408108 /usr/bin/nepomukservicestub 186376 /usr/bin/nepomukservicestub 176132 /usr/bin/nepomukservicestub 690664 /usr/bin/nepomukservicestub 2763740 /usr/bin/nepomukservicestub 218376 /usr/bin/nepomukservicestub 254672 grep nepomuk 7396 /usr/bin/akonadi_nepomuk_co 222776 See also http://forum.kde.org/viewtopic.php?f=154&t=85457&start=10 Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/2 ------------------------------------------------------------------------ On 2010-03-15T14:24:55+00:00 Paul Leopardi wrote: # uname -a Linux linfinit 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27 08:20:11 +0100 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/SuSE-release openSUSE 11.2 (x86_64) VERSION = 11.2 # rpm -q -f /usr/bin/nepomukservicestub kdebase4-runtime-4.4.1-192.1.x86_64 Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/3 ------------------------------------------------------------------------ On 2010-03-19T17:56:16+00:00 Iggy-mf wrote: why is this problem not confirmed? can reproduce this here. everytime strigi is indexing it eats up a lot of memory here and my system has to swap. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/4 ------------------------------------------------------------------------ On 2010-03-19T19:38:57+00:00 Trueg wrote: This bugs has been confirmed by many people and I can reproduce it, too. I suspect that you mean that you want the bug status to change. So I am doing that. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/5 ------------------------------------------------------------------------ On 2010-03-28T03:39:55+00:00 Smithjd15 wrote: I actually seemed to stumble across some interesting interactions and behaviour in running a 'find / sudo' after enabling compcache after every bootup. Access times seem to be updated and the entire filesystem 'ledger' is stored in compressed ram. What I did notice is reduced ram requirements in clementine as versus Amarok and of course in the filewatch daemon. Probably this is similar in scope to prelinking on Gentoo as far as feel goes, snake-oil-like. It may expose some workarounds for kernel behaviour and / or in Nepomuk behavior. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/6 ------------------------------------------------------------------------ On 2010-03-29T08:37:29+00:00 Smithjd15 wrote: (In reply to comment #6) > I actually seemed to stumble across some interesting interactions and > behaviour > in running a 'find / sudo' after enabling compcache after every bootup. > > Access times seem to be updated and the entire filesystem 'ledger' is stored > in > compressed ram. What I did notice is reduced ram requirements in clementine as > versus Amarok and of course in the filewatch daemon. > > Probably this is similar in scope to prelinking on Gentoo as far as feel goes, > snake-oil-like. It may expose some workarounds for kernel behaviour and / or > in > Nepomuk behavior. Improvements are to be noticed in shared memory mostly. Amarok isn't privy to shared memory on file handles anyway and so it doesn't show much improvement there..not being inclined to patch or dig any deeper into what calls are at issue, I used Amarok as a hardline reference and played around with Nepomuk / Clementine for a bit to assess file-handle economics. I'm still surprised how well compcache functions as a 'phreak'-like application; I haven't felt like I was hacking as such since my Atari ST days. Reply at: https://bugs.launchpad.net/kde-baseapps/+bug/569715/comments/7 ------------------------------------------------------------------------ On 2010-05-09T15:28:40+00:00 Tommy_CZ wrote: I can confirm this bug does affect me too. Linux tom-laptop 2.6.33-020633-generic #020633 SMP Thu Feb 25 10:10:03 UTC 2010 x86_64 GNU/Linux Kubuntu 10.04 Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/11 ------------------------------------------------------------------------ On 2010-05-10T19:25:14+00:00 Jan Baron wrote: I can confirm memory leak of nepomukservicestub too, often with virtuoso-t. It started after upgrading my system to Lucid Lynx KDE Platform Version: 4.4.2 (KDE 4.4.2) Qt Version: 4.6.2 Operating System: Linux 2.6.32-22-generic i686 Distribution: Ubuntu 10.04 LTS Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/12 ------------------------------------------------------------------------ On 2010-05-25T09:48:38+00:00 Vangelis Tasoulas wrote: Can confirm this bug too.... Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/13 ------------------------------------------------------------------------ On 2010-06-09T17:37:19+00:00 Getaceres-h wrote: Confirmed on Kubuntu 10.04 with KDE 4.4.2 Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/14 ------------------------------------------------------------------------ On 2010-06-10T21:07:36+00:00 Bugs-kde-3 wrote: Might be useful: http://thread.gmane.org/gmane.comp.kde.devel.core/63824 A mailing list thread where Sebastian asks for help in diagnosing the memory leak. Sebastian, did you try massif like suggested over there by Andreas Hartmetz? Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/15 ------------------------------------------------------------------------ On 2010-06-10T21:15:40+00:00 Bugs-kde-3 wrote: BTW, Sebastian, could it be related to the dangling metadata graphs that you wrote about (http://trueg.wordpress.com/2010/02/01/dangling-meta- data-graphs-caution-very-technical/)? On my machine, the query shows that I have 11717 such graphs: $ nepomukcmd query 'select count(?mg) where { ?mg nrl:coreGraphMetadataFor ?g . OPTIONAL { graph ?g { ?s ?p ?o . } . } . FILTER(!BOUND(?s)) . }' callret-0 -> "11717"^^<http://www.w3.org/2001/XMLSchema#int> Total results: 1 Execution time: 00:00:08.58 Is it a large number? Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/16 ------------------------------------------------------------------------ On 2010-07-21T23:01:26+00:00 Smithjd15 wrote: http://trac.pcbsd.org/changeset/7147 A BSD changeset related to CPU usage. While it's all accounted for, who can say what whale jumps? Degressing, how is this issue seen differently on BSD? Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/17 ------------------------------------------------------------------------ On 2011-01-06T16:25:55+00:00 Trueg wrote: It seems the memory leak was magically fixed by some changes unrelated to the search for this bug. Too bad we never figured out the real reason. It is still good to know the leak is gone. Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/18 ------------------------------------------------------------------------ On 2011-01-06T19:09:55+00:00 Trueg wrote: *** Bug 231409 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/19 ------------------------------------------------------------------------ On 2011-01-06T20:15:23+00:00 Trueg wrote: *** Bug 235377 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/20 ------------------------------------------------------------------------ On 2011-10-19T08:03:19+00:00 Hrogge wrote: Unfortunately it seems to be back in KDE 4.7 (or in Kubuntu 11.10 to be more correct). nepomukservicestub just runs my 4GB ram system at work out of memory, had do disable Nepomuk completely to get the memory back. Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/21 ------------------------------------------------------------------------ On 2011-10-24T15:49:17+00:00 Trueg wrote: Git commit 4f7a5d19da26af282f640c913afccad26000a388 by Sebastian Trueg. Committed on 24/10/2011 at 17:47. Pushed by trueg into branch 'KDE/4.7'. Run the MetaDataMover with an event loop. It is using the exact same approach as the file indexer does: a new thread is created and started and the MetaDataMover is then QObject::moveToThread'ed to it. This fixes mem leaks caused by DBus events that are not cleaned up. BUG: 226676 FIXED-IN: 4.7.3 M +70 -63 nepomuk/services/filewatch/metadatamover.cpp M +13 -10 nepomuk/services/filewatch/metadatamover.h M +9 -10 nepomuk/services/filewatch/nepomukfilewatch.cpp M +3 -1 nepomuk/services/filewatch/nepomukfilewatch.h http://commits.kde.org/kde- runtime/4f7a5d19da26af282f640c913afccad26000a388 Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/22 ------------------------------------------------------------------------ On 2011-10-24T15:49:21+00:00 Trueg wrote: Git commit 90afde5b3a488f89be2349085971655e6497f1bc by Sebastian Trueg. Committed on 24/10/2011 at 17:00. Pushed by trueg into branch 'master'. Run the MetaDataMover with an event loop. It is using the exact same approach as the file indexer does: a new thread is created and started and the MetaDataMover is then QObject::moveToThread'ed to it. This fixes mem leaks caused by DBus events that are not cleaned up. BUG: 226676 M +70 -63 services/filewatch/metadatamover.cpp M +13 -10 services/filewatch/metadatamover.h M +9 -10 services/filewatch/nepomukfilewatch.cpp M +3 -1 services/filewatch/nepomukfilewatch.h http://commits.kde.org/nepomuk- core/90afde5b3a488f89be2349085971655e6497f1bc Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/23 ------------------------------------------------------------------------ On 2011-10-24T18:49:41+00:00 Trueg wrote: Git commit 0f511184ae25364618ba244f6afda5570b02c388 by Sebastian Trueg. Committed on 24/10/2011 at 17:47. Pushed by trueg into branch 'master'. Run the MetaDataMover with an event loop. It is using the exact same approach as the file indexer does: a new thread is created and started and the MetaDataMover is then QObject::moveToThread'ed to it. This fixes mem leaks caused by DBus events that are not cleaned up. BUG: 226676 M +70 -63 nepomuk/services/filewatch/metadatamover.cpp M +13 -10 nepomuk/services/filewatch/metadatamover.h M +9 -10 nepomuk/services/filewatch/nepomukfilewatch.cpp M +3 -1 nepomuk/services/filewatch/nepomukfilewatch.h http://commits.kde.org/kde- runtime/0f511184ae25364618ba244f6afda5570b02c388 Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/24 ------------------------------------------------------------------------ On 2012-07-10T15:16:27+00:00 Jure Repinc wrote: Looks like this is back in 4.9 (I'm currently using RC1+ from git here). Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/26 ------------------------------------------------------------------------ On 2012-07-10T16:19:03+00:00 Jure Repinc wrote: Created attachment 72428 massif output This is the massif output after running a few minutes Reply at: https://bugs.launchpad.net/kde- baseapps/+bug/569715/comments/27 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/569715 Title: nepomukfilewatch leaks memory To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/569715/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
