Version: 3.7 (using KDE 4.5.5) OS: Linux 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. Reproducible: Sometimes OS: Linux (x86_64) release 2.6.34.7-0.7-desktop Compiler: gcc
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 connection is. Also this now should resolve the only remaining memleak with PA. CCMAIL: kde-multimedia@kde.org CCMAIL: kde-packager@kde.org CCMAIL: cguthrie@mandriva.org BUG: 264089 CCBUG: 237239 M +18 -3 mixer_pulse.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1241346