Bug 342374 - Memory Leak in plasma-desktop grows into gigabytes
Summary: Memory Leak in plasma-desktop grows into gigabytes
Status: RESOLVED UPSTREAM
Alias: None
Product: plasma4
Classification: Plasma
Component: notifications (show other bugs)
Version: 4.11.5
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-31 15:15 UTC by Shawn Cook
Modified: 2016-08-17 03:57 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
gnuplot of X vs plasma desktop over ~2.5 hours (5.86 KB, image/png)
2015-01-22 20:11 UTC, Matt W
Details
New crash information added by DrKonqi (6.50 KB, text/plain)
2015-01-26 05:05 UTC, Shawn Cook
Details
plasma-desktop went from 250MB to 3.5GB in 7 hours (6.67 KB, image/png)
2015-01-29 21:22 UTC, Matt W
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Cook 2014-12-31 15:15:18 UTC
+++ This bug was initially created as a clone of Bug #342044 +++

Application: kded4 (4.14.3)
KDE Platform Version: 4.14.3
Qt Version: 4.8.6
Operating System: Linux 3.17.6-200.fc20.x86_64 x86_64
Distribution: "Fedora release 20 (Heisenbug)"

-- Information about the crash:
- What I was doing when the application crashed:
Nothing out of the ordinary.  It's happened while just web browsing, while just emailing, while just using an ssh in konsole
- Unusual behavior I noticed:
The mouse and keyboard (usb logitech) become unresponsive, then the entire system becomes unresponsive.  Unplugging the devices from USB free the load and restore control.  This only started after the most recent kde update via yum (fedora)

The crash can be reproduced every time.

-- Backtrace:
Application: KDE Daemon (kded4), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
81	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
[Current thread is 1 (Thread 0x7f8776e348c0 (LWP 1985))]

Thread 5 (Thread 0x7f876aeaa700 (LWP 1989)):
#0  0x0000003d34c8a2ea in g_mutex_get_impl (mutex=0x7f87640009a0) at gthread-posix.c:124
#1  0x0000003d34c8a5c9 in g_mutex_unlock (mutex=mutex@entry=0x7f87640009a0) at gthread-posix.c:232
#2  0x0000003d34c48690 in g_main_context_acquire (context=0x7f87640009a0) at gmain.c:3141
#3  0x0000003d34c49465 in g_main_context_iterate (context=context@entry=0x7f87640009a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3663
#4  0x0000003d34c496dc in g_main_context_iteration (context=0x7f87640009a0, may_block=1) at gmain.c:3774
#5  0x0000003aa2fb541e in QEventDispatcherGlib::processEvents (this=0x7f87640008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#6  0x0000003aa2f8536f in QEventLoop::processEvents (this=this@entry=0x7f876aea9d10, flags=...) at kernel/qeventloop.cpp:149
#7  0x0000003aa2f856bd in QEventLoop::exec (this=this@entry=0x7f876aea9d10, flags=...) at kernel/qeventloop.cpp:204
#8  0x0000003aa2e79e5f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538
#9  0x0000003aa2e7c69f in QThreadPrivate::start (arg=0x2207860) at thread/qthread_unix.cpp:349
#10 0x0000003d32c07ee5 in start_thread (arg=0x7f876aeaa700) at pthread_create.c:309
#11 0x0000003d320f4b8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7f875f1ad700 (LWP 1996)):
#0  g_mutex_get_impl (mutex=0x7f87580009a0) at gthread-posix.c:123
#1  0x0000003d34c8a599 in g_mutex_lock (mutex=mutex@entry=0x7f87580009a0) at gthread-posix.c:213
#2  0x0000003d34c4959a in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7f87580029b0, timeout=-1, context=0x7f87580009a0) at gmain.c:4002
#3  g_main_context_iterate (context=context@entry=0x7f87580009a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3708
#4  0x0000003d34c496dc in g_main_context_iteration (context=0x7f87580009a0, may_block=1) at gmain.c:3774
#5  0x0000003aa2fb541e in QEventDispatcherGlib::processEvents (this=0x7f87580008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#6  0x0000003aa2f8536f in QEventLoop::processEvents (this=this@entry=0x7f875f1accc0, flags=...) at kernel/qeventloop.cpp:149
#7  0x0000003aa2f856bd in QEventLoop::exec (this=this@entry=0x7f875f1accc0, flags=...) at kernel/qeventloop.cpp:204
#8  0x0000003aa2e79e5f in QThread::exec (this=this@entry=0x2379120) at thread/qthread.cpp:538
#9  0x0000003aa2f65dc3 in QInotifyFileSystemWatcherEngine::run (this=0x2379120) at io/qfilesystemwatcher_inotify.cpp:265
#10 0x0000003aa2e7c69f in QThreadPrivate::start (arg=0x2379120) at thread/qthread_unix.cpp:349
#11 0x0000003d32c07ee5 in start_thread (arg=0x7f875f1ad700) at pthread_create.c:309
#12 0x0000003d320f4b8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f874cdd6700 (LWP 2097)):
#0  0x0000003d32c0e7fd in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x0000003d34c897b0 in read (__nbytes=16, __buf=0x7f874cdd5ac0, __fd=<optimized out>) at /usr/include/bits/unistd.h:44
#2  g_wakeup_acknowledge (wakeup=0x7f8728001c00) at gwakeup.c:212
#3  0x0000003d34c4909c in g_main_context_check (context=context@entry=0x7f87280009a0, max_priority=2147483647, fds=fds@entry=0x7f8728004260, n_fds=n_fds@entry=1) at gmain.c:3514
#4  0x0000003d34c49533 in g_main_context_iterate (context=context@entry=0x7f87280009a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3710
#5  0x0000003d34c496dc in g_main_context_iteration (context=0x7f87280009a0, may_block=1) at gmain.c:3774
#6  0x0000003aa2fb541e in QEventDispatcherGlib::processEvents (this=0x7f87280008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#7  0x0000003aa2f8536f in QEventLoop::processEvents (this=this@entry=0x7f874cdd5cd0, flags=...) at kernel/qeventloop.cpp:149
#8  0x0000003aa2f856bd in QEventLoop::exec (this=this@entry=0x7f874cdd5cd0, flags=...) at kernel/qeventloop.cpp:204
#9  0x0000003aa2e79e5f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538
#10 0x00007f875ff60b17 in KCupsConnection::run() () from /lib64/libkcupslib.so
#11 0x0000003aa2e7c69f in QThreadPrivate::start (arg=0x22b24a0) at thread/qthread_unix.cpp:349
#12 0x0000003d32c07ee5 in start_thread (arg=0x7f874cdd6700) at pthread_create.c:309
#13 0x0000003d320f4b8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f872ffff700 (LWP 2098)):
#0  0x0000003d34c8a2ea in g_mutex_get_impl (mutex=0x7f87200009a0) at gthread-posix.c:124
#1  0x0000003d34c8a599 in g_mutex_lock (mutex=mutex@entry=0x7f87200009a0) at gthread-posix.c:213
#2  0x0000003d34c48bf9 in g_main_context_prepare (context=context@entry=0x7f87200009a0, priority=priority@entry=0x7f872fffebd0) at gmain.c:3342
#3  0x0000003d34c494bb in g_main_context_iterate (context=context@entry=0x7f87200009a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3693
#4  0x0000003d34c496dc in g_main_context_iteration (context=0x7f87200009a0, may_block=1) at gmain.c:3774
#5  0x0000003aa2fb541e in QEventDispatcherGlib::processEvents (this=0x7f87200008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#6  0x0000003aa2f8536f in QEventLoop::processEvents (this=this@entry=0x7f872fffed10, flags=...) at kernel/qeventloop.cpp:149
#7  0x0000003aa2f856bd in QEventLoop::exec (this=this@entry=0x7f872fffed10, flags=...) at kernel/qeventloop.cpp:204
#8  0x0000003aa2e79e5f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538
#9  0x0000003aa2e7c69f in QThreadPrivate::start (arg=0x255ede0) at thread/qthread_unix.cpp:349
#10 0x0000003d32c07ee5 in start_thread (arg=0x7f872ffff700) at pthread_create.c:309
#11 0x0000003d320f4b8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f8776e348c0 (LWP 1985)):
[KCrash Handler]
#6  0x00007f87605b0eb2 in XRandRConfig::toKScreenConfig() const () from /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so
#7  0x00007f87609df4fc in Serializer::currentId() () from /usr/lib64/kde4/kded_kscreen.so
#8  0x00007f87609dfa62 in Serializer::configExists() () from /usr/lib64/kde4/kded_kscreen.so
#9  0x00007f87609de7f2 in KScreenDaemon::applyConfig() () from /usr/lib64/kde4/kded_kscreen.so
#10 0x0000003aa2f9b35a in QMetaObject::activate (sender=0x22a92c0, m=<optimized out>, local_signal_index=<optimized out>, argv=0x0) at kernel/qobject.cpp:3567
#11 0x00007f87605ba608 in XRandROutput::updateKScreenOutput(KScreen::Output*) const () from /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so
#12 0x00007f87605b119b in XRandRConfig::updateKScreenConfig(KScreen::Config*) const () from /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so
#13 0x00007f87607cbce9 in KScreen::ConfigMonitor::Private::updateConfigs() () from /lib64/libkscreen.so.1
#14 0x00007f87607cbd3d in KScreen::ConfigMonitor::notifyUpdate() () from /lib64/libkscreen.so.1
#15 0x00007f87605ae282 in XRandR::updateOutput(unsigned long) () from /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so
#16 0x0000003aa2f9b35a in QMetaObject::activate (sender=0x2298b00, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fff63b75c00) at kernel/qobject.cpp:3567
#17 0x00007f87605afbb4 in XRandRX11Helper::x11Event(_XEvent*) () from /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so
#18 0x00007f87796c536c in publicX11Event (e=0x7fff63b75d10, this=<optimized out>) at /usr/src/debug/kdelibs-4.14.3/kdeui/kernel/ksystemeventfilter.cpp:43
#19 KSystemEventFilterPrivate::filterEvent (this=0x2263240, message=0x7fff63b75d10) at /usr/src/debug/kdelibs-4.14.3/kdeui/kernel/ksystemeventfilter.cpp:102
#20 0x0000003aa2f77f2e in QAbstractEventDispatcher::filterEvent (this=0x3d323b7760 <main_arena>, message=0x3d323b7760 <main_arena>, message@entry=0x7fff63b75d10) at kernel/qabstracteventdispatcher.cpp:542
#21 0x00007f87789ddaae in x11EventSourceDispatch (s=s@entry=0x1fdae20, callback=0x0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:145
#22 0x0000003d34c492a6 in g_main_dispatch (context=0x1fdad60) at gmain.c:3066
#23 g_main_context_dispatch (context=context@entry=0x1fdad60) at gmain.c:3642
#24 0x0000003d34c49628 in g_main_context_iterate (context=context@entry=0x1fdad60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#25 0x0000003d34c496dc in g_main_context_iteration (context=0x1fdad60, may_block=1) at gmain.c:3774
#26 0x0000003aa2fb541e in QEventDispatcherGlib::processEvents (this=0x1fa9ea0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#27 0x00007f87789ddc46 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#28 0x0000003aa2f8536f in QEventLoop::processEvents (this=this@entry=0x7fff63b76100, flags=...) at kernel/qeventloop.cpp:149
#29 0x0000003aa2f856bd in QEventLoop::exec (this=this@entry=0x7fff63b76100, flags=...) at kernel/qeventloop.cpp:204
#30 0x0000003aa2f8ad89 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#31 0x00007f877893a4ec in QApplication::exec () at kernel/qapplication.cpp:3823
#32 0x00007f8779fb12ce in kdemain (argc=1, argv=0x7fff63b76388) at /usr/src/debug/kdelibs-4.14.3/kded/kded.cpp:940
#33 0x0000003d32021d65 in __libc_start_main (main=0x4007e0 <main(int, char**)>, argc=1, argv=0x7fff63b76388, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff63b76378) at libc-start.c:285
#34 0x0000000000400811 in _start ()

Possible duplicates by query: bug 336718, bug 335646, bug 334947.

Reported using DrKonqi
Comment 1 Shawn Cook 2014-12-31 16:16:14 UTC
Additional Information:
I've repeatedly seen the follow increase plasma-desktop memory size at a rate of 2M per second for hundreds of megabytes.
----------------------------------------------------------------------------------------------------------------------------------
-Kopete spinning icon in system tray (always)
Bouncing icon by pointer when launching an application (most of the time)
::: Removing the system tray applet does not stop plasma-desktop from leaking, only prevents these 2 sources
::: Using system tray widget instead of applet does not stop the memory leak either

-Desktop Folder Widget, moving the mouse over any icons in the folder widget would increase plasma-desktop memory size by roughly .5M to 1M per second until all had be hovered, then after a few seconds it would again begin growing upon hovering.

I have been monitoring my system under little to no load and I've found that plasma-desktop will consume ram until it forces swapping and then the swap used will grow until the system freezes.  I've also found these entires in the messages log:
Dec 18 04:42:18 localhost kernel: [22336.857390] Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 04:42:18 localhost kernel: [22336.859305] Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 04:42:18 localhost kernel: Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 04:42:19 localhost kernel: Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 04:42:18 localhost kernel: Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 04:42:19 localhost kernel: Out of memory: Kill process 2218 (plasma-desktop) score 823 or sacrifice child
Dec 18 15:39:00 localhost kernel: [23509.678942] Out of memory: Kill process 2205 (plasma-desktop) score 693 or sacrifice child
Dec 18 15:39:00 localhost kernel: [23514.703722] Out of memory: Kill process 2205 (plasma-desktop) score 693 or sacrifice child
Dec 18 15:39:30 localhost kernel: Out of memory: Kill process 2205 (plasma-desktop) score 693 or sacrifice child
Dec 18 15:39:30 localhost kernel: Out of memory: Kill process 2205 (plasma-desktop) score 693 or sacrifice child
Dec 19 02:54:12 localhost kernel: [31023.577804] Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 19 02:54:41 localhost kernel: [31052.134485] Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 19 02:54:42 localhost kernel: Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 19 02:54:42 localhost kernel: Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 19 02:54:42 localhost kernel: Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 19 02:54:42 localhost kernel: Out of memory: Kill process 2237 (plasma-desktop) score 792 or sacrifice child
Dec 20 00:20:00 localhost kernel: [29825.945429] Out of memory: Kill process 2234 (plasma-desktop) score 766 or sacrifice child
Dec 20 00:20:00 localhost kernel: [29825.946721] Out of memory: Kill process 2234 (plasma-desktop) score 766 or sacrifice child
Dec 20 00:20:01 localhost kernel: Out of memory: Kill process 2234 (plasma-desktop) score 766 or sacrifice child
Dec 20 00:20:01 localhost kernel: Out of memory: Kill process 2234 (plasma-desktop) score 766 or sacrifice child

I have not reliably identified any one single trigger and the memory growth is slow unless I'm using the system heavily.  I have found though that jut walking away and returning 8 hours later after no use and the plasma-desktop utilization has grown.  I've disabled desktop search and it continues.  I haven't used other Activities.
Comment 2 mathew 2015-01-12 15:03:08 UTC
I believe this may be the reintroduced bug 314919, with the system tray applet and icon changes causing memory leakage. Can anyone check and confirm?

https://bugs.kde.org/show_bug.cgi?id=314919
Comment 3 Christoph Feck 2015-01-14 16:18:11 UTC
Shawn, please clarify: Are you reporting a crash here or not? If you are not reporting a crash, I suggest to file a bug report without a backtrace.
Comment 4 Shawn Cook 2015-01-14 16:58:21 UTC
(In reply to Christoph Feck from comment #3)
> Shawn, please clarify: Are you reporting a crash here or not? If you are not
> reporting a crash, I suggest to file a bug report without a backtrace.

I apologize, I'm not sure.  I started by reporting a crash.  After a few times I started monitoring my system and saw an unconstrained memory leak in plasma-desktop and then went further to find multiple ways to push the leak.  Do note: I have two separate systems, different hardware with the same issue.  Please advise as to a proper course of action.
Comment 5 mathew 2015-01-19 19:25:37 UTC
So what do I need to provide to get some action? This is making KDE unusable. I booted at 08:30, it's 13:30 now, and plasma-workspace has already ballooned to 10.2GB resident, 14.9GB total.

Whether it's a crash or not depends on how long you leave it!

Is there any way to do a controlled restart of plasma-workspace without ruining the desktop environment?
Comment 6 mathew 2015-01-19 19:31:15 UTC
...sorry, to answer my own question, for the benefit of others having this problem:

Yes, you can kill plasma-desktop, and then run   plasma-desktop &   and it'll grind away for a while and bring back your menus. One of my windows spontaneously moved itself, but other than that everything came back usable.

I think my next step will be to write a quick program that monitors plasma-desktop, and kills it and restarts it when it hogs too much RAM...
Comment 7 Shawn Cook 2015-01-20 00:45:57 UTC
I have since used this in my .bashrc
alias newplasma='pkill -f plasma-desktop; sleep 3; plasma-desktop > /dev/null 2>&1 &'

Whenever I see it cresting 1 gig I fire it off.  Anyone know how to automate it based on memory consumption?
Comment 8 Matt W 2015-01-22 16:51:23 UTC
I don't know how to help with this, but I want to add that I am having these issues as well.

I am running 2 desktops:

Fedora 20 with 8GB or ram, 3GB of swap.
Fedora 21 with 16GB or ram, 4 GB of swap

On both of these systems I can usually hit the bug within 24 hours of starting the computer up.  plasma-desktop spins out of control and consume all of my RAM and all of my SWAP on each computer.  It brings the whole system to halt.  I have been rebooting to fix it, but it has been coming back too quickly.

I run into this about once a day, so I can help debug, I'm just not sure what to look at.

On Fedora 20, I'm running kde-workspace-4.11.14-2.fc20.x86_64

I don't have my Fedora 21 box up so I can not get the version I am running there.  It is current.
Comment 9 Shawn Cook 2015-01-22 16:54:17 UTC
To Prevent System Crashes I use this:  At 800mb it restarts plasma-desktop
#!/bin/bash
CURRENTMEM="$(smem|grep [p]lasma-desktop|awk '{print $5}'| sed -e 's/^ *//' -e 's/ *$//')"
MEMCAP=800000
if [[ $CURRENTMEM -gt $MEMCAP ]] ; then
`pkill -f plasma-desktop; sleep 3; plasma-desktop > /dev/null 2>&1 &`
fi;
Comment 10 Shawn Cook 2015-01-22 16:54:54 UTC
(In reply to Shawn Cook from comment #9)
> To Prevent System Crashes I use this:  At 800mb it restarts plasma-desktop
> #!/bin/bash
> CURRENTMEM="$(smem|grep [p]lasma-desktop|awk '{print $5}'| sed -e 's/^ *//'
> -e 's/ *$//')"
> MEMCAP=800000
> if [[ $CURRENTMEM -gt $MEMCAP ]] ; then
> `pkill -f plasma-desktop; sleep 3; plasma-desktop > /dev/null 2>&1 &`
> fi;
then just put it in cron to check every minute
Comment 11 Hussam Al-Tayeb 2015-01-22 16:58:30 UTC
(In reply to Matt W from comment #8)
> I don't know how to help with this, but I want to add that I am having these
> issues as well.
> 
> I am running 2 desktops:
> 
> Fedora 20 with 8GB or ram, 3GB of swap.
> Fedora 21 with 16GB or ram, 4 GB of swap
> 
> On both of these systems I can usually hit the bug within 24 hours of
> starting the computer up.  plasma-desktop spins out of control and consume
> all of my RAM and all of my SWAP on each computer.  It brings the whole
> system to halt.  I have been rebooting to fix it, but it has been coming
> back too quickly.
> 
> I run into this about once a day, so I can help debug, I'm just not sure
> what to look at.
> 
> On Fedora 20, I'm running kde-workspace-4.11.14-2.fc20.x86_64
> 
> I don't have my Fedora 21 box up so I can not get the version I am running
> there.  It is current.

So on one machine plasma-desktop used 16GB of memory in 24 hours? How much memory is Xorg using and what graphics driver are you using?
What plasma applets are you running?
Comment 12 Matt W 2015-01-22 17:03:19 UTC
Yes, it will consume all my memory sometimes in 6-8 hours.  It won't get me through a work day, sometimes.  Sometimes it will go a couple of days, but it will take it all up.

I run Nvidia on both machines.  On Fedora 20, I use:

 kmod-nvidia-3.17.7-200.fc20.x86_64-331.113-1.fc20.x86_64

Again, F21 isn't up, but I believe it's nvidia version 346.

I run 3 montitors, with a panel on each.  I run task manager in each.  I run YAWP (yet another weather plugin), and then pager, kmenu, a few apps, and then a notification bar.  The 3 monitors might accelerate the problem, I don't know.
Comment 13 Shawn Cook 2015-01-22 17:08:10 UTC
(In reply to Matt W from comment #12)
> Yes, it will consume all my memory sometimes in 6-8 hours.  It won't get me
> through a work day, sometimes.  Sometimes it will go a couple of days, but
> it will take it all up.
> 
> I run Nvidia on both machines.  On Fedora 20, I use:
> 
>  kmod-nvidia-3.17.7-200.fc20.x86_64-331.113-1.fc20.x86_64
> 
> Again, F21 isn't up, but I believe it's nvidia version 346.
> 
> I run 3 montitors, with a panel on each.  I run task manager in each.  I run
> YAWP (yet another weather plugin), and then pager, kmenu, a few apps, and
> then a notification bar.  The 3 monitors might accelerate the problem, I
> don't know.

I just wanted to add:  This problem continues even without any widgets or panels other than a single simple panel.  Slower, but it still continues to grow.  (for me at least).
Comment 14 Hussam Al-Tayeb 2015-01-22 17:10:34 UTC
(In reply to Matt W from comment #12)
> Yes, it will consume all my memory sometimes in 6-8 hours.  It won't get me
> through a work day, sometimes.  Sometimes it will go a couple of days, but
> it will take it all up.
> 
> I run Nvidia on both machines.  On Fedora 20, I use:
> 
>  kmod-nvidia-3.17.7-200.fc20.x86_64-331.113-1.fc20.x86_64
> 
> Again, F21 isn't up, but I believe it's nvidia version 346.
> 
> I run 3 montitors, with a panel on each.  I run task manager in each.  I run
> YAWP (yet another weather plugin), and then pager, kmenu, a few apps, and
> then a notification bar.  The 3 monitors might accelerate the problem, I
> don't know.

Does removing yaWP help? Try using kdeplasma-addons' weather applet instead and see if the memory usage gets better. Some unofficial plasma applets often cause issues.

Another thing to try is check if Xorg memory usage is increasing. If that is increasing, it could mean some pixmaps are being cached, and re-cached instead of being read from memory.
Comment 15 Shawn Cook 2015-01-22 17:25:44 UTC
(In reply to Hussam Al-Tayeb from comment #14)
> (In reply to Matt W from comment #12)
> > Yes, it will consume all my memory sometimes in 6-8 hours.  It won't get me
> > through a work day, sometimes.  Sometimes it will go a couple of days, but
> > it will take it all up.
> > 
> > I run Nvidia on both machines.  On Fedora 20, I use:
> > 
> >  kmod-nvidia-3.17.7-200.fc20.x86_64-331.113-1.fc20.x86_64
> > 
> > Again, F21 isn't up, but I believe it's nvidia version 346.
> > 
> > I run 3 montitors, with a panel on each.  I run task manager in each.  I run
> > YAWP (yet another weather plugin), and then pager, kmenu, a few apps, and
> > then a notification bar.  The 3 monitors might accelerate the problem, I
> > don't know.
> 
> Does removing yaWP help? Try using kdeplasma-addons' weather applet instead
> and see if the memory usage gets better. Some unofficial plasma applets
> often cause issues.
> 
> Another thing to try is check if Xorg memory usage is increasing. If that is
> increasing, it could mean some pixmaps are being cached, and re-cached
> instead of being read from memory.

You can use xrestop to see if pixmaps are growing on you and consuming the ram.  (For me) they did not.
Comment 16 Matt W 2015-01-22 20:11:28 UTC
Created attachment 90588 [details]
gnuplot of X vs plasma desktop over ~2.5 hours

This is a gnuplot of my X vs plasma-desktop RSS Memory process usage
Comment 17 Matt W 2015-01-22 20:15:28 UTC
I just attached a png of gnuplot.  This might be overdone, or not helpful, but I find it interesting.

I am tracking RSS of plasma-desktop process and the X process.  This is in Fedora 20.  I went to lunch + had a meeting from 13:00-14:30 and locked my desktop.  It appears that the memory stopped growing during that time.  When I came back, the memory started shooting up again.  I am gathering at a 5 minute interval (cron).  I will continue to watch it, I find it interesting.

To me, it looks like it's growing at 200MB an hour on my system.  X seems to be flat, not growing at all.

If there is interest I will share my cron script and gnuplot script.
Comment 18 Matt W 2015-01-22 20:16:25 UTC
Two notes. 

1) i disabled yawp as requested.
2) I restarted plasma-desktop within an hour of this graph data starting up.
Comment 19 Hussam Al-Tayeb 2015-01-22 20:26:55 UTC
wow. It is starting at close to 400MB.
Comment 20 Shawn Cook 2015-01-22 20:46:56 UTC
(In reply to Hussam Al-Tayeb from comment #19)
> wow. It is starting at close to 400MB.

What does your plasma-desktop start around?  Mine starts around 300MB.
Comment 21 Shawn Cook 2015-01-22 20:47:34 UTC
(In reply to Matt W from comment #17)
> I just attached a png of gnuplot.  This might be overdone, or not helpful,
> but I find it interesting.
> 
> I am tracking RSS of plasma-desktop process and the X process.  This is in
> Fedora 20.  I went to lunch + had a meeting from 13:00-14:30 and locked my
> desktop.  It appears that the memory stopped growing during that time.  When
> I came back, the memory started shooting up again.  I am gathering at a 5
> minute interval (cron).  I will continue to watch it, I find it interesting.
> 
> To me, it looks like it's growing at 200MB an hour on my system.  X seems to
> be flat, not growing at all.
> 
> If there is interest I will share my cron script and gnuplot script.

I watched at my worst that mine increased ~2MBps
Comment 22 Hussam Al-Tayeb 2015-01-22 20:52:17 UTC
(In reply to Shawn Cook from comment #20)
> (In reply to Hussam Al-Tayeb from comment #19)
> > wow. It is starting at close to 400MB.
> 
> What does your plasma-desktop start around?  Mine starts around 300MB.

Around 78MB when I started it an hour ago. It is up to 106.5 MB now.
In my case, it seems to be the notification area and system tray that are causing the memory increase.
Comment 23 Rex Dieter 2015-01-22 20:56:13 UTC
Sounds like many of the recent comments have little to do with the original report (and seems to have little to do with kscreen).

OK, which systray applets do you use?  Do you have any applications that employ active/changing/animating legacy (Xembed) systray icons?  If so, what are they?
Comment 24 Hussam Al-Tayeb 2015-01-22 21:02:11 UTC
(In reply to Rex Dieter from comment #23)
> Sounds like many of the recent comments have little to do with the original
> report (and seems to have little to do with kscreen).
> 
> OK, which systray applets do you use?  Do you have any applications that
> employ active/changing/animating legacy (Xembed) systray icons?  If so, what
> are they?

The only things I have in my systray are the notfication thing, weather applet from plasma-addons, the "Available devices" thing, clock applet, kopete, konversation and korgac.
Comment 25 Hussam Al-Tayeb 2015-01-22 21:05:45 UTC
(In reply to Hussam Al-Tayeb from comment #24)
> (In reply to Rex Dieter from comment #23)
> > Sounds like many of the recent comments have little to do with the original
> > report (and seems to have little to do with kscreen).
> > 
> > OK, which systray applets do you use?  Do you have any applications that
> > employ active/changing/animating legacy (Xembed) systray icons?  If so, what
> > are they?
> 
> The only things I have in my systray are the notfication thing, weather
> applet from plasma-addons, the "Available devices" thing, clock applet,
> kopete, konversation and korgac.
Memory used by plasma-desktop increases every time there is a new notification (for a example 'new mail has arrived'). Clearing the notifications doesn't decrease the memory usage.
Comment 26 Shawn Cook 2015-01-22 21:18:05 UTC
(In reply to Hussam Al-Tayeb from comment #25)
> (In reply to Hussam Al-Tayeb from comment #24)
> > (In reply to Rex Dieter from comment #23)
> > > Sounds like many of the recent comments have little to do with the original
> > > report (and seems to have little to do with kscreen).
> > > 
> > > OK, which systray applets do you use?  Do you have any applications that
> > > employ active/changing/animating legacy (Xembed) systray icons?  If so, what
> > > are they?
> > 
> > The only things I have in my systray are the notfication thing, weather
> > applet from plasma-addons, the "Available devices" thing, clock applet,
> > kopete, konversation and korgac.
> Memory used by plasma-desktop increases every time there is a new
> notification (for a example 'new mail has arrived'). Clearing the
> notifications doesn't decrease the memory usage.

I removed the System Tray applet and notifications and the memory leak still occurs.  Yes I'm able to force the leak by creating animation in some of the applets icons or forcing notifications, but the removal of it does not stop the leak, merely slows it down.
Comment 27 Rex Dieter 2015-01-23 16:01:17 UTC
Re-assigned to plasma/notifications , which seems to be the most popular explanation so far, based on the evidence.
Comment 28 Shawn Cook 2015-01-26 05:05:01 UTC
Created attachment 90663 [details]
New crash information added by DrKonqi

plasma-desktop (4.11.14) on KDE Platform 4.14.3 using Qt 4.8.6

- What I was doing when the application crashed:

Absolutely nothing for about 2 hours.  I was watching a movie on another computer.

-- Backtrace (Reduced):
#6  XRandROutput::update (this=this@entry=0x31, primary=primary@entry=XRandROutput::NoChange) at /usr/src/debug/libkscreen-1.0.5/backends/xrandr/xrandroutput.cpp:130
#7  0x00007f3272453ec0 in XRandRConfig::toKScreenConfig (this=0x235a960) at /usr/src/debug/libkscreen-1.0.5/backends/xrandr/xrandrconfig.cpp:121
#8  0x00007f3272880a4e in KScreenApplet::slotConfigurationChanged (this=0x235b340) at /usr/src/debug/kscreen-1.0.2.1/plasma/kscreenapplet.cpp:265
#9  0x00007f327288245d in KScreenApplet::qt_static_metacall (_o=0x235b340, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /usr/src/debug/kscreen-1.0.2.1/x86_64-redhat-linux-gnu/plasma/kscreenapplet.moc:71
[...]
#11 0x00007f327266ea80 in KScreen::ConfigMonitor::configurationChanged (this=<optimized out>) at /usr/src/debug/libkscreen-1.0.5/x86_64-redhat-linux-gnu/src/configmonitor.moc:103
Comment 29 Alberto 2015-01-27 15:33:02 UTC
I'm copying my report from https://bugs.kde.org/show_bug.cgi?id=314919, since this looks more like the issue I'm having.

Since I've upgraded to Fedora 21 (KDE 4.14.3-4) I've been experiencing +huge+ memory leaks. The scenario is as follows:

- At system startup (monitoring with htop) VIRT usage by kdeinit4: plasma-desktop is just about 3000MB. RES about 300MB, SHR about 100MB
- Memory usage keeps increasing. After some hours, VIRT can reach up to 16GB(!) which leads to high swap usage. However, xrestop doesn't show any increments.
- I've not been able to relate it to any particular application, but it seems that 'heavy' ones (like Eclipse) take a high toll on memory usage. However, after closing all open apps, VIRT (and SHR/RES) don't get back to normal. The only way to reduce them is to reset X system.
Comment 30 Matt W 2015-01-29 21:21:58 UTC
Fedora 21.

$ /bin/plasma-desktop -v    
Qt: 4.8.6
KDE Development Platform: 4.14.3
Plasma Desktop Shell: 4.11.14

Is there any additional data I can provide, steps to do, that will help with this bug?  

I am going to add another attachement of today's memory usage.  plasma-desktop went from 250MB of memory to about 3.5GB in about 7 hours today.  It's crazy.
Comment 31 Matt W 2015-01-29 21:22:38 UTC
Created attachment 90794 [details]
plasma-desktop went from 250MB to 3.5GB in 7 hours
Comment 32 Rex Dieter 2015-01-29 21:24:29 UTC
Mention which plasma applets you use + any application that animates systray icon + any application that sends a significant number of notifications.

For example, debugging the other day, I found a clementine user (double whammy of animiated systray icon + spammy notifications) caused plasma-desktop to go up on every track change.
Comment 33 Matt W 2015-01-29 21:29:40 UTC
I have 3 monitors.  Each monitor has one Panel.  2 of the monitors just has task manager on the panel.

On my main monitor, I have a panel with task manager, the fedora menu, the workspace monitor, and the notifcation tray. I have chrome notifications up there and I get thunderbird email notifications in there.  I get a lot of email in thunderbird, so It does notify me quite a bit.   I have a network manager that is connected to the vpn, but it doesn't seem to do any animations.  I use KVIRC and it has a notification monitor up there as well.

I do not have any plasma applets on my desktop running.
Comment 34 Alberto 2015-01-31 18:59:11 UTC
In desktop: quicklaunch pad
In panel: Kickoff, activity manager, clock, kmix, skype, clipboard, devices, keyboard switcher... mostly the default fedora KDE settings (it's a fresh F21 install).
As I told before, the party begins when I work with Eclipse. Without it, mem usage growth is much slower.
Right now, system uptime is 7:46 and this is htop's output:


  1  [|||||                                     7.8%]     Tasks: 116, 296 thr; 1 running
  2  [|||||                                     7.8%]     Load average: 0.16 0.29 0.31 
  3  [|||||                                     8.2%]     Uptime: 07:50:13
  4  [|||||                                     8.1%]
  Mem[|||||||||||||||||||||||||||||||||||6553/7927MB]
  Swp[|||||||||||||||||||||||||||||||||| 5876/8191MB]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 1815 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1817 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1818 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1819 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1827 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1828 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1829 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.00 kdeinit4: plasma-desktop [kdeinit]
 1839 aln        20   0 14.2G 4554M 66304 S  0.0 57.4  0:00.81 kdeinit4: plasma-desktop [kdeinit]
 1810 aln        20   0 14.2G 4554M 66304 S 11.8 57.4  1h09:23 kdeinit4: plasma-desktop [kdeinit]
Comment 35 Alberto 2015-02-04 15:26:49 UTC
Some new findings, in case they are any help...
- Animated ("bouncing") startup icons (i.e. when starting Skype) make VIRT usage go up at abount 1M/sec. VIRT stops growing when the icon disappears.
- When starting up Chrome plasma-desktop VIRT goes up to 84G (not a typo!), but after a while reverts to the previous value. However, this happens only with Chrome ( 40.0.2214.93 ).
Comment 36 Christoph Feck 2015-02-15 17:13:16 UTC
Alberto, does comment #34 tell me that there are multiple "plasma-desktop" processes running on your system?
Comment 37 Christoph Feck 2015-02-15 17:16:57 UTC
... and given that this bug reports introduces itself with a backtrace (and is starting to attract other users reporting the same KScreen crash, see comment #28), I suggest to create a new report with your findings.

Which update broke it? Which widget or action is responsible?
Comment 38 Alberto 2015-02-15 18:54:56 UTC
Cristoph, 

Yes, htop and ps always report multiple plasma-desktop processes.

Some new findings: the Chrome issue seems unrelated, it's just a Chrome component that momentarily takes a huge chunk of memory, but after a while it's released.

What I've found is that taskbar notifications are clearly causing memory usage to go through the roof. The following scenario is 100% reproducible:
- Open a terminal window with htop
- plasma-desktop VIRT is more or less stable
- Start krusader.
- Perform a copy/move of a directory with lots of files.
- Open the queued jobs icon in the taskbar, and zoom the krusader job, where all the files being copied will be displayed in succession.
- plasma-desktop VIRT will go up at a rate of over 2MB/sec
- after the copy/move is finished, memory usage will remain stable

Bouncing startup icons also make memory usage grow, but as they are usually animated only for a short time, the effect is not as noticeable.

So it seems any kind of animation is contributing to the problem.
Comment 39 Shawn Cook 2015-02-16 00:58:33 UTC
(In reply to Christoph Feck from comment #37)
> ... and given that this bug reports introduces itself with a backtrace (and
> is starting to attract other users reporting the same KScreen crash, see
> comment #28), I suggest to create a new report with your findings.
> 
> Which update broke it? Which widget or action is responsible?

Christoph,
I thought it was an update that broke it but another computer I had with the same install (and not recently updated prior to this discovery) still had the same problem only I wasn't using it so I never noticed.  I've got a script running that tracks the plasma-desktop memory usage every 5 seconds and alerts me when it passes 1gb and it doesn't take very long.  I find myself restarting the service every hour or two.  Even with no widgets running the memory issue exists but as others have said, animation in the taskbar is the worst offender.  I have only a single instance of plasma-desktop at any point in time.
Comment 40 Łukasz 2015-02-27 02:50:54 UTC
I've been experiencing similar things with my Fedora 20 since an upgrade of kde-plasma-nm.

I filed a bug report with Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1175578

The most serious memory leak happens with Rekonq and Choqok. Choqok actually takes forever to load and to turn off, but the memory leak also happens without them.

It's really serious, makes KDE almost unusable.
Comment 41 Vladislav Vorobiev 2015-02-28 14:32:14 UTC
This bug is also in my debian KDE

$ plasma-desktop -v
Qt: 4.8.6
KDE Development Platform: 4.14.2
Plasma Desktop Shell: 4.11.13

It makes kde unusable for normal users!
I get this bug on only one of my 3 PC's with similar (same) configuration.
Comment 42 mathew 2015-02-28 20:34:52 UTC
I tried the KDE 5 preview, and that doesn't have the problem, which makes me suspect strongly that it's the code for handling legacy systray icons — as KDE 5 drops support for those APIs.

Unfortunately, KDE 5 has other problems that make it not ready for use yet, so I've switched to XFCE temporarily so I can get work done :-(
Comment 43 Alberto 2015-05-19 11:49:26 UTC
Just a little 'bump' for this bug... I understand there might be more serious issues, but I think this is a rather important one, and it's still in unconfirmed state. Just wanted to know whether it will be fixed in KDE4 or not. Or maybe it's just affecting a small number of users.

Thanks!
Comment 44 Christoph Feck 2015-05-19 11:54:09 UTC
Alberto, did you fix comment #36 yet? If not, please try a LiveCD, and find out what you need to configure to reproduce the issues you see.
Comment 45 Alberto 2015-05-20 10:24:06 UTC
Cristoph, yesterday I tried (same test scenario as described in #38) with the F21 Beta LiveCD (the one I initially used for the HD install) and the problem seems not to appear. BTW, the multiple plasma-desktop processes are in fact threads shown by htop, but there is only one process.
I've also tried to disable the nvidia driver using nouveau instead (just in case) but memory usage is increasing anyway.
Comment 46 mathew 2015-05-20 14:09:12 UTC
Yes, it's definitely nothing to do with proprietary drivers, I've never used anything but nouveau.
Comment 47 Dmitry 2015-11-03 13:31:05 UTC
I've this bug in my system: NV GF9800 with blob, Arch 64, KDE. Every time on any action with plasmoids (activate popups in tray, switching virtual screens, showing|hiding calendar etc.) the 'top' utility show increasing of memory usage by plasma-desktop for 1-5 MB (in the 'RES' column). Plasma-desktop can grow memory usage to 2-3 GB per day.
Comment 48 Dmitry 2015-11-03 13:31:31 UTC
I've this bug in my system: NV GF9800 with blob, Arch 64, KDE. Every time on any action with plasmoids (activate popups in tray, switching virtual screens, showing|hiding calendar etc.) the 'top' utility show increasing of memory usage by plasma-desktop for 1-5 MB (in the 'RES' column). Plasma-desktop can grow memory usage to 2-3 GB per day.
Comment 49 Dmitry 2015-11-03 13:31:49 UTC
I've this bug in my system: NV GF9800 with blob, Arch 64, KDE. Every time on any action with plasmoids (activate popups in tray, switching virtual screens, showing|hiding calendar etc.) the 'top' utility show increasing of memory usage by plasma-desktop for 1-5 MB (in the 'RES' column). Plasma-desktop can grow memory usage to 2-3 GB per day.
Comment 50 Dmitry 2015-11-03 23:42:57 UTC
Was fixed for me by installing the 'freetype2' instead of the 'freetype2-infinality-git', installed earlier. Looks like this was memory leak in the  'freetype2-infinality-git'.
Comment 51 Alberto 2015-11-10 17:53:50 UTC
Yep, Dmitry is right... I've also uninstalled freetype-infinality and the problem went away.
Comment 52 Sebastian Kügler 2016-08-17 03:57:14 UTC
Closing this bug, it's apparently an upstream problem, and not an issue in Plasma 5, anyway.

Thanks for the report, anyway.