Version: 3.7 (using KDE 4.5.5)
When Kmix starts, it typically uses 6-8 Mb RAM according to "System Activity". However, after several days of running, it's memory usage grows quite high. E.g., see attached screenshot - 238Mb. Once, after resume from hibernation, Kmix's memory usage was over 700Mb.
OS: Linux (x86_64) release 188.8.131.52-0.7-desktop
Created attachment 56351 [details]
KMix memory leak
I'm replicating this in 4.6 using any Phonon backend, currently kmix is using 1.6GB of RAM.
Duplicate of Bug #264292?
I see the same on Kubuntu 10.10 Linux 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC 2011 x86_64 (quad core) KDE 4.6.2. After 10 days kmix uses 191 MB according to System Activity. This is a desktop machine that is always on. I don't use hibernation nor suspend-to-RAM.
SVN commit 1241346 by sitter:
Do not emit signals directly but queue invokeMethod them to resolve
a memleak in KMix/Oxygen caused by PA callbacks.
Oxygen internally uses deleteLater to remove fancy animations from widgets.
Every time PA changes its sinks (for example on track change in a Phonon player),
KMix recreates its sliders thus causing animation creation inside the oxygen style.
On deletion of old sliders the oxygen additions should get deleted.
However since the switching originates in a direct call
chain from PA (via callback -> mixer impl -> emit -> kmix UI internals -> oxygen) the
deleteLater does not actually do anything and never gets executed thus leaking memory
big time (12 hours of music -> >100MB of leaked memory).
To resolve this issue the PA mixer now does not directly emit signals anymore (which
translates to a direct function call) but instead uses the mixer's QMetaObject to
deploy a *queued* invokeMethod call to the signal (therefore forcing queued emission
and execution in the QEventLoop/QThread of the target, which in our case is the
main application thread rather than the calling back PA thread).
This has the advantage that even additional connections to the mixer singals
will always get a queued emission neverminding what the type of the actual
Also this now should resolve the only remaining memleak with PA.
M +18 -3 mixer_pulse.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1241346