Bug 309464

Summary: kmix: media track change memory leaks with pulseaudio+oxygen widget style
Product: kmix Reporter: Jekyll Wu <adaptee>
Component: generalAssignee: Christian Esken <esken>
Status: RESOLVED FIXED    
Severity: normal CC: apcomptec, aspotashev, cfeck, chgonzalezg, civil.over, daniel, dimkard, evgom.sid, fisiu82, gonssal, griwes, hugo.pereira.da.costa, jgrulich, jirislaby, jospoortvliet, kde-malc, kdebugzilla, l12436.tw, lukas, markehammons, martin.holec, muesli, rael.gc, rdieter, semekh.dev+kde, sitter, sol, sonichedgehog_hyperblast00, trebor_x, walter.von.entferndt
Priority: HI    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 4.11.0
Attachments: kmix memory usage shown in ksysguard
Valgrind memcheck with Pulseaudio Backend
Fix the small memory leak caused by unnecessarily creating object on heap
memory leak log created by valgrind
kmix error create by valgrind
kmix memory leak both record and playback.
kmix debug output
kmix debug output
Kmix running with valgrind
applies to master (or KDE/4.10) branch.

Description Jekyll Wu 2012-11-03 09:30:05 UTC
I accidentally noticed that kmix took up 100MB memory on the heap (see the screenshot).  I don't think that is a normal level for an application like kmix.

Unfortunately I  currently have no idea how to reproduce and provide more information. I notice it totally by accident.

I'm using kmix built from git master 


Reproducible: Sometimes
Comment 1 Jekyll Wu 2012-11-03 09:31:14 UTC
Created attachment 74954 [details]
kmix memory usage shown in ksysguard
Comment 2 Christian Esken 2012-11-14 00:31:22 UTC
Confirmed.
I had an eye on it in the last days, and I found memory always increases (about 0,5MB) each time when changing tracks in Amarok using the KMix Pulseaudio backend. It might be in the PA Backend or a generic KMix leak. I suspect the latter, for example the View might not clean itself properly.

Work hint: Until KDE4.9 the View was fully reconstructed on a stream add/delete, and in that case cleaned.
Comment 3 Torsten Eichstädt 2012-12-06 14:00:24 UTC
Confirmed. I stumbled upon this by chance, too.  KMix uses slightly more than 100MB, and the heap increases by 1.3 MB when I change a track in Amarok - _sometimes_.  The memory is not freed when I close Amarok (that's neccessary to switch to an internet radio stream, but that' s another story...).  Perhaps the increase at my machine is bigger because my system is 64 bit and Christian Esken's is 32.  I use Phonon backend for GStreamer.
Comment 4 Christian Esken 2012-12-08 08:33:40 UTC
Git commit 0817891cb834fdbf06307f3e990b42ae533accc3 by Christian Esken.
Committed on 08/12/2012 at 09:33.
Pushed by esken into branch 'master'.

Fix memory leaks

M  +2    -0    apps/kmix.cpp
M  +1    -0    gui/osdwidget.cpp

http://commits.kde.org/kmix/0817891cb834fdbf06307f3e990b42ae533accc3
Comment 5 Christian Esken 2012-12-08 08:36:14 UTC
Root cause seems to be that MixDevice instances are not freed. There is a lot memory attached to a MixDevice, and for example the corresponding DBus object will also not be freed. This should easily be provable with qdbusviewer.
Comment 6 Christian Esken 2012-12-08 09:31:42 UTC
Looks like there is a cycle in the object references:
- MixDevice has a DBusControlWrapper.
- DBusControlWrapper holds a ref to the MixDevice

So there is always a reference alive, which means automatic collection of MixDevice can not kick in. Both objects are not reachable any longer, but due to simple reference kept alive.

Possible solution:
 Add an explicit "free ressources" method to MixDevice.
Comment 7 Christian Esken 2012-12-08 11:54:24 UTC
Git commit 3be72f8202b27342baa504c09b91f2bcfa381bf6 by Christian Esken.
Committed on 08/12/2012 at 12:51.
Pushed by esken into branch 'master'.

Fix memory leaks, especially related to the MixDevice - DBusControlWrapper reference cycle.

M  +3    -1    backends/mixer_alsa9.cpp
M  +31   -5    backends/mixer_backend.cpp
M  +19   -2    backends/mixer_backend.h
M  +6    -1    backends/mixer_mpris2.cpp
M  +0    -1    backends/mixer_oss.cpp
M  +0    -1    backends/mixer_oss4.cpp
M  +8    -2    backends/mixer_pulse.cpp
M  +0    -1    backends/mixer_sun.cpp
M  +18   -1    core/mixdevice.cpp
M  +2    -0    core/mixdevice.h
M  +1    -1    core/mixer.cpp
M  +1    -0    gui/viewbase.cpp
M  +2    -2    gui/viewbase.h
M  +2    -5    gui/viewdockareapopup.cpp

http://commits.kde.org/kmix/3be72f8202b27342baa504c09b91f2bcfa381bf6
Comment 8 Christian Esken 2012-12-08 11:59:12 UTC
Memory leakage has been greatly reduced. The remaining issues are:
 - ControlManager::announce(QString, ControlChangeType::Type, QString) (ControlManager.cpp:76) . This is important, as the mehtod is called often
 - Various leaks and access to invalid memory (already freed) in the Pulseaudio backend, that revolve around calls to the libpulse.so library.
Comment 9 Christian Esken 2012-12-08 12:15:51 UTC
Created attachment 75706 [details]
Valgrind memcheck with Pulseaudio Backend

Valgrind memcheck with Pulseaudio Backend Methodology: 
- Start pulseaudio
 - Run leak check like this: valgrind -v --leak-resolution=high --num-callers=20 --tool=memcheck --show-reachable=yes --leak-check=yes kmix --nofork > o2 2> valgrind.leakcheck.kmix-pulse.txt 

The most interesting part is possibly pa_context_set_sink_volume_by_index(), and anything else run from Mixer_PULSE::writeVolumeToHW().

Hint: The KMix debug output is "mixed in" with the Valgrind output (STDERR == STDOUT).
Comment 10 Christian Esken 2012-12-08 14:10:38 UTC
Git commit 16e6d336ddc60365d0b36af7636a3a0fad3d2d9e by Christian Esken.
Committed on 08/12/2012 at 15:09.
Pushed by esken into branch 'master'.

Fix some more memory leaking.

M  +1    -0    backends/mixer_alsa9.cpp
M  +7    -6    backends/mixer_backend.cpp
M  +2    -2    backends/mixer_backend.h
M  +2    -0    backends/mixer_mpris2.cpp
M  +1    -0    backends/mixer_oss.cpp
M  +1    -0    backends/mixer_oss4.cpp
M  +3    -0    backends/mixer_pulse.cpp
M  +1    -0    backends/mixer_sun.cpp
M  +1    -1    core/mixer.cpp
M  +1    -1    gui/osdwidget.cpp
M  +5    -0    gui/viewdockareapopup.cpp

http://commits.kde.org/kmix/16e6d336ddc60365d0b36af7636a3a0fad3d2d9e
Comment 11 Christian Esken 2012-12-08 14:12:50 UTC
Leak summary, before first commit on 2012-11-08):
==5863== LEAK SUMMARY:
==5863==    definitely lost: 7,740 bytes in 95 blocks
==5863==    indirectly lost: 58,512 bytes in 589 blocks
==5863==      possibly lost: 181,622 bytes in 3,861 blocks
==5863==    still reachable: 289,830 bytes in 3,409 blocks
==5863==         suppressed: 0 bytes in 0 blocks

Leak summary, after commiting http://commits.kde.org/kmix/16e6d336ddc60365d0b36af7636a3a0fad3d2d9e
==25790== LEAK SUMMARY:
==25790==    definitely lost: 7,428 bytes in 85 blocks
==25790==    indirectly lost: 18,878 bytes in 276 blocks
==25790==      possibly lost: 139,020 bytes in 2,544 blocks
==25790==    still reachable: 315,293 bytes in 3,483 blocks
==25790==         suppressed: 0 bytes in 0 blocks
Comment 12 Christian Esken 2012-12-08 15:26:57 UTC
Please test the current version or KDE 4.10 RC1. Behavior should be much better there (still not perfect, but hopefully acceptable enough for now, until we can fix the remaining locations).
Comment 13 Torsten Eichstädt 2012-12-08 17:24:25 UTC
Am Samstag, 8. Dezember 2012, 15:26:57 schrieben Sie:
> --- Comment #12 from Christian Esken <esken@kde.org> ---
> Please test the current version or KDE 4.10 RC1. Behavior should be much
> better there (still not perfect, but hopefully acceptable enough for now,
> until we can fix the remaining locations).

Seems to me that this is fixed with the updates yesterday, Dec 7th 2012.
Now kmix uses 5 MB, compared to >100 MB before.

@Christian Esken:
If you use "Re: " before the subject, the mail viewers can automagically group 
mails to a thread.
Comment 14 Jekyll Wu 2012-12-30 12:51:44 UTC
@Christian, the situation is really much better than before. 

Running the valgrind check in comment #7, I notice there are mainly three issues remaining. 

==23231== 54 (16 direct, 38 indirect) bytes in 1 blocks are definitely lost in loss record 773 of 1,312
==23231==    at 0x4029A1E: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23231==    by 0x40D3CE2: ControlManager::addListener(QString, ControlChangeType::Type, QObject*, QString) (ControlManager.cpp:126)
==23231==    by 0x40CDE1C: OSDWidget::OSDWidget(QWidget*) (osdwidget.cpp:80)
==23231==    by 0x4098D98: KMixWindow::initActions() (kmix.cpp:238)
==23231==    by 0x40A2CCD: KMixWindow::KMixWindow(bool) (kmix.cpp:87)
==23231==    by 0x40A3F17: KMixApp::newInstance() (KMixApp.cpp:108)

This one is not a big deal. Will attach a trivial patch. 



==23231== 360 (80 direct, 280 indirect) bytes in 2 blocks are definitely lost in loss record 1,229 of 1,312
==23231==    at 0x4029A1E: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23231==    by 0x40AB2CE: ViewDockAreaPopup::add(std::tr1::shared_ptr<MixDevice>) (viewdockareapopup.cpp:291)
==23231==    by 0xA3FD727: ???

This one is a big problem.  ProfControl objects are created very often (every time I switch to next track in amarok ) but *never* destoryed according to my added debugging message.  Each track switching causes kmix creating 8 more ProfControl objects and consumes about 100K more heap memory.


==23231== 1,800 (288 direct, 1,512 indirect) bytes in 4 blocks are definitely lost in loss record 1,271 of 1,312
==23231==    at 0x4029A1E: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23231==    by 0x40CBE4F: GUIProfile::fallbackProfile(Mixer*) (guiprofile.cpp:280)
==23231==    by 0xA523447: ???

No idea whethe this warning is true.
Comment 15 Jekyll Wu 2012-12-30 12:54:52 UTC
Created attachment 76090 [details]
Fix the small memory leak caused by unnecessarily creating object on heap
Comment 16 Christian Esken 2012-12-31 15:24:55 UTC
Comment on attachment 76090 [details]
Fix the small memory leak caused by unnecessarily creating object on heap

Just a short review, as I am not at my computer at the moment: It looks correct, as  (like Jekyll correcty noted) listeners contains objects, so listeners.append(...)  will create a copy of the Listener object. Listener does not have an explicit copy constructor, but as a shallow copy is OK for all fields of Listener.
Comment 17 Christian Esken 2012-12-31 15:36:53 UTC
(In reply to comment #14)
> @Christian, the situation is really much better than before. 
> 
> Running the valgrind check in comment #7, I notice there are mainly three
> issues remaining. 
> 
> ==23231== 54 (16 direct, 38 indirect) bytes in 1 blocks are definitely lost
> in loss record 773 of 1,312
> ==23231==    at 0x4029A1E: operator new(unsigned int) (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==23231==    by 0x40D3CE2: ControlManager::addListener(QString,
> ControlChangeType::Type, QObject*, QString) (ControlManager.cpp:126)
> ==23231==    by 0x40CDE1C: OSDWidget::OSDWidget(QWidget*) (osdwidget.cpp:80)
> ==23231==    by 0x4098D98: KMixWindow::initActions() (kmix.cpp:238)
> ==23231==    by 0x40A2CCD: KMixWindow::KMixWindow(bool) (kmix.cpp:87)
> ==23231==    by 0x40A3F17: KMixApp::newInstance() (KMixApp.cpp:108)
> 
> This one is not a big deal. Will attach a trivial patch. 
> 
> 
> 
> ==23231== 360 (80 direct, 280 indirect) bytes in 2 blocks are definitely
> lost in loss record 1,229 of 1,312
> ==23231==    at 0x4029A1E: operator new(unsigned int) (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==23231==    by 0x40AB2CE:
> ViewDockAreaPopup::add(std::tr1::shared_ptr<MixDevice>)
> (viewdockareapopup.cpp:291)
> ==23231==    by 0xA3FD727: ???
> 
> This one is a big problem.  ProfControl objects are created very often
> (every time I switch to next track in amarok ) but *never* destoryed
> according to my added debugging message.  Each track switching causes kmix
> creating 8 more ProfControl objects and consumes about 100K more heap memory.

I agree, Jekyll. The problem here is that object ownership is unclean. I added a comment on 08/12/2012 :
// Leak | relevant | pctl Each time a stream is added, a new ProfControl gets created.
// It cannot be deleted in ~MixDeviceWidget, as ProfControl* ownership is not consistent.

I must say that 100K seems to be excessive. I do not see so much here, but I guess numbers might vary wildly from platform to platform, installed harware and setup.
Comment 18 Christian Esken 2013-01-02 19:38:13 UTC
I verified the patch for the small leak at ControlManager.cpp:126. It looks fine. I will commit it.

There is another small leak nearby at ControlManager.cpp:117, which I do not understand at all, because the leak is somewhere below of  KDebug::operator()(int).


==20429== 8 bytes in 1 blocks are still reachable in loss record 140 of 1,314
==20429==    at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20429==    by 0x82B3D02: QMutexPool::createMutex(int) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.3)
==20429==    by 0x83CBDD1: QMetaObjectPrivate::disconnect(QObject const*, int, QObject const*, int, QMetaObjectPrivate::DisconnectType) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.3)
==20429==    by 0x83CC843: QObject::disconnect(QObject const*, char const*, QObject const*, char const*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.3)
==20429==    by 0x835A9AC: QTextStream::QTextStream(QIODevice*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.3)
==20429==    by 0x7C05FA8: KDebugPrivate::stream(QtMsgType, unsigned int, char const*, int, char const*) (qdebug.h:65)
==20429==    by 0x7C01A25: kDebugStream(QtMsgType, int, char const*, int, char const*) (kdebug.cpp:776)
==20429==    by 0x4E5BA0E: KDebug::operator()(int) (kdebug.h:260)
==20429==    by 0x4EB2423: ControlManager::addListener(QString, ControlChangeType::Type, QObject*, QString) (ControlManager.cpp:117)
==20429==    by 0x4E5AC01: DBusMixerWrapper::DBusMixerWrapper(Mixer*, QString const&) (dbusmixerwrapper.cpp:46)
==20429==    by 0x4EB6781: Mixer::openIfValid(int) (mixer.cpp:288)
==20429==    by 0x4EAF7BA: MixerToolBox::possiblyAddMixer(Mixer*) (mixertoolbox.cpp:311)
==20429==    by 0x4EAF065: MixerToolBox::initMixerInternal(MixerToolBox::MultiDriverMode, QList<QString>, QString&) (mixertoolbox.cpp:166)
==20429==    by 0x4EAEAC6: MixerToolBox::initMixer(MixerToolBox::MultiDriverMode, QList<QString>, QString&) (mixertoolbox.cpp:85)
==20429==    by 0x4EAEA77: MixerToolBox::initMixer(bool, QList<QString>, QString&) (mixertoolbox.cpp:80)
==20429==    by 0x4E79C2B: KMixWindow::KMixWindow(bool) (kmix.cpp:95)
==20429==    by 0x4E85586: KMixApp::newInstance() (KMixApp.cpp:108)
==20429==    by 0x59C9146: KUniqueApplication::Private::_k_newInstanceNoFork() (kuniqueapplication.cpp:370)
==20429==    by 0x83C943D: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.3)
==20429==    by 0x7025F93: QApplication::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.3)
Comment 19 Christian Esken 2013-01-02 19:39:37 UTC
Git commit a732145921beb8bc49b6c860c083c5b1a1c5ed4b by Christian Esken.
Committed on 02/01/2013 at 20:39.
Pushed by esken into branch 'master'.

Fix a small memory leak

M  +2    -2    core/ControlManager.cpp

http://commits.kde.org/kmix/a732145921beb8bc49b6c860c083c5b1a1c5ed4b
Comment 20 Christian Esken 2013-01-02 21:11:55 UTC
Git commit 1b32e22bffe9194518ef59b97a9920490ed496a6 by Christian Esken.
Committed on 02/01/2013 at 22:09.
Pushed by esken into branch 'KDE/4.10'.

Fix a small memory leak

M  +3    -2    core/ControlManager.cpp

http://commits.kde.org/kmix/1b32e22bffe9194518ef59b97a9920490ed496a6
Comment 21 Christian Esken 2013-01-02 22:35:02 UTC
Git commit 09aabd4a344e045eb3a554f47fb7f1f6b43cf2ac by Christian Esken.
Committed on 02/01/2013 at 23:31.
Pushed by esken into branch 'master'.

Fix the ProfControl memory leak in ViewDockAreaPopup

M  +11   -2    gui/viewdockareapopup.cpp
M  +4    -0    gui/viewdockareapopup.h

http://commits.kde.org/kmix/09aabd4a344e045eb3a554f47fb7f1f6b43cf2ac
Comment 22 Christian Esken 2013-01-02 22:36:39 UTC
New leak summary, after http://commits.kde.org/kmix/09aabd4a344e045eb3a554f47fb7f1f6b43cf2ac :

==10051== LEAK SUMMARY:
==10051==    definitely lost: 6,180 bytes in 51 blocks
==10051==    indirectly lost: 16,904 bytes in 247 blocks
==10051==      possibly lost: 137,169 bytes in 2,596 blocks
==10051==    still reachable: 304,638 bytes in 3,487 blocks
==10051==         suppressed: 0 bytes in 0 blocks
Comment 23 Christian Esken 2013-01-02 23:25:42 UTC
Git commit 8a4a135e2885ede8848bbc961632ab65cf8239ee by Christian Esken.
Committed on 03/01/2013 at 00:24.
Pushed by esken into branch 'master'.

Document the memory ownership of GUIProfile, explain possible (but unlikely) memory leak scenarios.

M  +17   -1    gui/guiprofile.cpp

http://commits.kde.org/kmix/8a4a135e2885ede8848bbc961632ab65cf8239ee
Comment 24 Jekyll Wu 2013-01-08 15:51:45 UTC
*** Bug 312891 has been marked as a duplicate of this bug. ***
Comment 25 TOM Harrison 2013-01-14 12:42:50 UTC
i have make the newest vesion of kmix.
and it seems it did not solve already.
will it fix in the next RC ?
Comment 26 jos poortvliet 2013-01-25 20:12:50 UTC
See http://wstaw.org/m/2013/01/25/plasma-desktopkM8435.png - kmix uses over 500 mb after using my PC for a few days... This is KDE SC 4.10 RC2. I'd suggest this as blocker for release as it makes using Plasma Desktop on a computer with 1 GB of ram without a restart every day almost impossible. (changing volume is terribly slow, as in, can take up to minutes to react with high CPU usage - and this is a 8GB ram, quadcore PC).
Comment 27 Christian Esken 2013-02-04 19:13:20 UTC
Jos, does the trunk version work better for you? I fixed the last few fixable issues there, but I wouldn't expect that they accumulate up to such a huge number.
If running trunk doesn't help, please try without PulseAudio. The last Valgrind check suggests there are PA related leaks, but as far as I see they are in the PA library and not in the KMix PA back end .
Comment 28 Jan Grulich 2013-02-18 22:16:44 UTC
I just found out that switching songs in Clementine increases memory usage of kmix. I was in the moment when kmix used 300MB of memory. I'm using KDE 4.10 and PA 2.1.
Comment 29 Jan Grulich 2013-02-18 22:33:02 UTC
It seems it's a bug in PA, when I disabled it, kmix uses the same amount of memory.
Comment 30 Christian Esken 2013-02-22 23:26:44 UTC
Thanks for testing, Jan.  If someone could open a bug report at PulseAudio [1] it could speed up things.  I cannot do currently for ressource reasons.

[1] https://bugs.freedesktop.org/
Comment 31 TOM Harrison 2013-02-23 09:21:19 UTC
i tested the another backends MPRIS2
and i play music in clementine.
it did not show in the kmix.
so i can not test that if real pulseaudio bug.
Comment 32 TOM Harrison 2013-02-23 09:23:21 UTC
(In reply to comment #31)
> i tested the another backends MPRIS2
> and i play music in clementine.
> it did not show in the kmix.
> so i can not test that if real pulseaudio bug.

and i test the amarok player.
it dost not increase  the memory.
Comment 33 TOM Harrison 2013-02-23 09:59:55 UTC
Created attachment 77523 [details]
memory leak log created by valgrind
Comment 34 TOM Harrison 2013-02-23 10:03:35 UTC
i have upload memory leak log created by valgrind
because your kmix program will exit after execute.

it seems in the beginning of the kmix.
it has memory leak.

is there any way to keep kmix running in the console.
i need to use the valgrind to check the memory leak
Comment 35 TOM Harrison 2013-02-23 10:05:35 UTC
and the valgrind program is telled by
https://bugs.freedesktop.org/show_bug.cgi?id=61336
this bug report.
Comment 36 Christian Esken 2013-02-23 11:38:14 UTC
Thanks. It seems to indicate relevant locations.  Unfortunately you did not have debug symbols for KMix (shows only "??? (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)"). Could you install them. If you don't want to  make KMix terminate immediately, you must quit KMix and then start it like this:
  kmix --nofork
The recommended way is:
  valgrind -v --leak-resolution=high --num-callers=20 --tool=memcheck  --show-reachable=yes --leak-check=yes kmix --nofork
Comment 37 TOM Harrison 2013-02-23 14:26:35 UTC
Created attachment 77526 [details]
kmix error create by valgrind
Comment 38 TOM Harrison 2013-02-23 14:47:56 UTC
Created attachment 77528 [details]
kmix memory leak both record and playback.
Comment 39 TOM Harrison 2013-02-23 14:51:08 UTC
i use the Audacity to both record and playback.
because i just finish configure the input through the alsa.
and it seems has the memory leak, too.
Comment 40 Christian Esken 2013-02-23 15:26:07 UTC
Quite  interesting stuff in there, for example:

Mixer_ALSA::addVolume() leaks. [1] This is unexpected. 
ViewDockAreaPopup::add() leaks. [2] OUCH
more ...

Just wondering why I don't see it when I run valgrind. Oh, I just saw:

> and i play music in clementine.
> and i test the amarok player. it dost not increase the memory.

Clementine is a special case. Probably I create stuff for Clementine, discard it, but forget to delete. I must check that!




[1]
==19557== 432 bytes in 9 blocks are definitely lost in loss record 1,250 of 1,426
==19557==    at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19557==    by 0x4E65187: Mixer_ALSA::addVolume(_snd_mixer_elem*, bool) (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)
==19557==    by 0x4E6693D: Mixer_ALSA::open() (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)
==19557==    by 0x4E5DD29: Mixer_Backend::openIfValid() (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)


[2]
==19557== 17,640 (5,040 direct, 12,600 indirect) bytes in 70 blocks are definitely lost in loss record 1,423 of 1,426
==19557==    at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19557==    by 0x4E84DAC: ViewDockAreaPopup::add(std::tr1::shared_ptr<MixDevice>) (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)
==19557==    by 0x4E8454E: ViewBase::createDeviceWidgets() (in /usr/lib/kde4/libkdeinit/libkdeinit4_kmix.so)
==19557==    by 0x83A49B6: QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
Comment 41 Jiri Slaby 2013-02-23 19:56:59 UTC
FWIW I'm still seeing this with 4.10. kmix just had 500M of RSS before I killed that...
Comment 42 Jiri Slaby 2013-02-23 19:58:53 UTC
Nicely reproducible with:
while :; do paplay /usr/share/sounds/KDE_Beep_Ahem.wav ; sleep 1; done
Comment 43 Torsten Eichstädt 2013-02-23 21:35:31 UTC
(In reply to comment #42)
> Nicely reproducible with:
> while :; do paplay /usr/share/sounds/KDE_Beep_Ahem.wav ; sleep 1; done

FYI: Because maybe this might help to find the bug: I could not reproduce on FreeBSD 9.1 (PC-BSD 9.1) KDE 4.9.3 -- although kmix has 60M RSS, quite a lot IMHO, but it does not grow when I repeately play a WAV or OGG file.

Good luck!
Comment 44 TOM Harrison 2013-02-24 01:57:31 UTC
actually when i use the Audacity or amaork.
there also has memory leak.
Comment 45 TOM Harrison 2013-02-24 02:00:07 UTC
i forget to say.
my computer has install both alsa and pulseaudio, and being configured.
i have enable this.

load-module module-alsa-sink device=dmix
load-module module-alsa-source device=dsnoop

to make the pulseaudio work normal with alsa.
Comment 46 Jan Grulich 2013-03-16 20:06:48 UTC
Created attachment 78116 [details]
kmix debug output

I don't know if this will help, but here is the debug output with what is happening in kmix after switching to the next song.
Comment 47 Jan Grulich 2013-03-16 20:09:07 UTC
Created attachment 78117 [details]
kmix debug output

I don't know if this will help, but here is the debug output with what is happening in kmix after switching to the next song.
Comment 48 Erick Osorio 2013-03-16 23:12:47 UTC
Well... when i play Age of Empires II - Conquerors with wine, kmix up to 470MB in 30 mins...

Looks like a very critical bug.
Comment 49 Marc González Majoral 2013-03-21 13:15:06 UTC
I honestly don't understand why anyone would like to run PulseAudio or Kmix considering how TERRIBLE they are at what they do, but I just gave it a try to remember when my computer got frozen every 10 minutes for no reason.

After 8 minutes of Amarok running, Kmix spiking to 800-900MB of RAM used (4GB system), constant hard disk reading that freezes plasma, etc...

Just remove PulseAudio and Kmix and make yourself able to use your computer again and be productive. And don't even try them again. Ever.
Comment 50 Marc González Majoral 2013-03-21 13:16:45 UTC
I honestly don't understand why anyone would like to run PulseAudio or Kmix considering how TERRIBLE they are at what they do, but I just gave it a try to remember when my computer got frozen every 10 minutes for no reason.

After 8 minutes of Amarok running, Kmix spiking to 800-900MB of RAM used (4GB system), constant hard disk reading that freezes plasma, etc... Kubuntu 12.10 with backports and running 4.10.1. Problem already existed with 4.8.4 and 4.9.X, don't know if worse or not. Disable PulseAudio and Kmix and everything works perfect.

Just remove PulseAudio and Kmix and make yourself able to use your computer again and be productive. And don't even try them again. Ever.
Comment 51 TOM Harrison 2013-03-21 14:55:06 UTC
if the MPRIS2 could catch the all sound stream, i would not use the pulseaudio.
but now the MPRIS2 just could catch the few sound stream.
and most of them is kde app.
Comment 52 Jiri Slaby 2013-03-21 18:13:13 UTC
(In reply to comment #50)
> I honestly don't understand why anyone would like to run PulseAudio or Kmix
> considering how TERRIBLE they are at what they do, but I just gave it a try
> to remember when my computer got frozen every 10 minutes for no reason.

Stop that shit. I see no reason why you posted that crap here in the first place.
Comment 53 Torsten Eichstädt 2013-03-21 19:13:09 UTC
(In reply to comment #52)

Take it easy.  Maybe he once wrote a 50-liner without memory leaks... :)

I wrote some time ago that I can not reproduce the bug on FreeBSD, but I could 
on Linux.  Thus I think it is likely in some lower library?  Or a compiler 
switch that is different on those two?
Comment 54 Marc González Majoral 2013-03-22 09:40:21 UTC
(In reply to comment #52)
> (In reply to comment #50)
> > I honestly don't understand why anyone would like to run PulseAudio or Kmix
> > considering how TERRIBLE they are at what they do, but I just gave it a try
> > to remember when my computer got frozen every 10 minutes for no reason.
> 
> Stop that shit. I see no reason why you posted that crap here in the first
> place.

I was just trying to make the guy uninstall PulseAudio and Kmix to make his desktop usable again, so he can enjoy his computer without trashing KDE and switching to another DE that doesn't make you look at the screen for 5 minutes every now and then, with your HD reading and writing like crazy due to memory leaks in two apps that are useless to the regular user and haven't been fixed since 4.7.X

Sorry if it sounded harsh.
Comment 55 Jekyll Wu 2013-04-11 21:44:43 UTC
*** Bug 318204 has been marked as a duplicate of this bug. ***
Comment 56 jos poortvliet 2013-04-17 09:37:37 UTC
I think bugzilla needs to have a way to remove idiotic comments like some above. In any case, I can report that KMix does still continuously grow over about a week, I have to kill it every now and then. Changing volume becomes real slow and memory goes to 200+ mb in about 4-5 days. kquitapp kmix && kmix of course brings it back to normal levels for a while.

I'm running kde sc 4.10.2 from openSUSE packages. Anything I can do to help debug this? Run valgrind on it or something?
Comment 57 Rex Dieter 2013-04-18 18:06:44 UTC
So, hanging out in #kde-multimedia with nothing better to do, had some fun with markey and sandsmark.

I generated a fresh valgrind memleak and massif logs running kmix kde git master from today (2013-04-18) + amarok and playing through 20 songs @ approx 10 seconds each:
http://rdieter.fedorapeople.org/valgrind.leakcheck.kmix-pulse.txt
http://rdieter.fedorapeople.org/massif.out.18864
respectively.

the latter ended up being the interesting one, sandsmark generated a pretty graph,
http://wstaw.org/m/2013/04/18/plasma-desktophya504.png

which seems to highlight most of the heap used in QPropertyAnimation, and he suspected oxygen style may play a role.  So, for giggles, I tried:
kmix --style plastique

and at least according to ksysguard, kmix memory usage stays constant (@ 10,208k) no matter how many track changes I try.
Comment 58 TOM Harrison 2013-04-19 02:12:03 UTC
i have tried, too
the increase of memory disappear.
and i use the original kmix used by oxygen.
then the increase of memory happened.
so this is oxygen error ?
Comment 59 Erick Osorio 2013-04-19 04:52:27 UTC
Rex you rigth, with style plastique, the leak its gone. Just 1MB up with various songs and 30 mins of Age of Empires II (before this should be like 400 MB).
Comment 60 TOM Harrison 2013-04-19 06:20:32 UTC
the pulseaudio website say his program did not has memory leak.
so he say the memory  leak is caused by kmix
Comment 61 Rex Dieter 2013-04-20 05:46:03 UTC
*** Bug 318552 has been marked as a duplicate of this bug. ***
Comment 62 Daniel 2013-04-30 17:33:32 UTC
I can confirm using style plastique fixes multiple issues. My issues were

* Memory leak - kmix reached 1.5GB yesterday
* 100% cpu usage on a core when toggling volume with hardware controls
* opening kmix from systray and adjusting volume was not fluid - roughly 1 sec before slider would adjust to a new value

I'm also using pulse audio and oxygen application theme (but not oxygen plasma theme)
Comment 63 Neal Becker 2013-05-02 00:33:04 UTC
Yes, plastik seems to work.  But I hate it.  Is there any other themes that work?
Comment 64 Daniel 2013-05-02 18:13:50 UTC
i'm pretty sure the themes available are the same thing in system settings
-> application appearance -> style

So for example, if you have the gtk+ oxygen theme installed, you could try

$ killall kmix
$ kmix --style gtk+

And have something that looks near like oxygen, though the vertical
separator in the popup is all white, but the controls look normal.


On Wed, May 1, 2013 at 7:33 PM, Neal Becker <ndbecker2@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=309464
>
> --- Comment #63 from Neal Becker <ndbecker2@gmail.com> ---
> Yes, plastik seems to work.  But I hate it.  Is there any other themes that
> work?
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You are on the CC list for the bug.
>
Comment 65 Mark Hammons 2013-05-09 13:34:56 UTC
I'm getting 500-750MB memory usage by kmix.
Comment 66 Rex Dieter 2013-05-09 15:51:27 UTC
updating summary to match findings so far (pulseaudio + oxygen + media track changes)
Comment 67 Jekyll Wu 2013-05-10 14:50:45 UTC
Add oxygen maintainer per discussions since comment #57
Comment 68 Rael Gugelmin Cunha 2013-05-15 12:07:35 UTC
Using Kubuntu 12.04 + KDE ppa backports (KDE 4.10.3). Noticed that Kmix reached 400MB of RAM usaged.

Using Oxygen Style. But appears to be weird a style produce this. Even with other styles, people above said to see memory increasing, even smaller, but still increasing.

Is there any alternative for Kmix? It's too responsible for a long response delay after users login.
Comment 69 Hugo Pereira Da Costa 2013-05-15 12:24:20 UTC
Hi,

First, I do not think there is a leak in oxygen directly (otherwise, pretty much all applications would leak, when using oxygen style). (this would for instance also include kwin).

Now there might be leaks upstream that are made worth by oxygen.  For instance, concerning QPropertyAnimation mentionned in comment 57, these guys are allocated by oxygen (to deal with ... animations) every time a new QWidget is created, and deleted (really, they are) when the widget is destroyed. Widget not destroy -> animation not destroyed, and leak is made worse.  (these animations are obviously not created when using any other widget style).

In any case, I seem to be able to reproduce the issue with the "paplay" trick mentionned in comment 42, so I'll investigate some more (who knows: oxygen might be able to tell me which is actually the qwidget that is not destroyed). 

Will keep you posted. 

Hugo
Comment 70 Rael Gugelmin Cunha 2013-05-15 15:18:38 UTC
Just if I can add something in the discussion: my use is always to playback streaming radios. So, I stop/pause a lot of times in a day.

I had the same issue using Amarok or Clementine.
Comment 71 Rael Gugelmin Cunha 2013-05-15 15:54:04 UTC
By the way, I switched to veromix in this meantime:

sudo apt-get install plasma-widget-veromix

Enabled the widget on systray and disabled KmixD on KDE Startup.

Now I have a mixer using 8Mb instead of 400Mb, even after several start/stop/pause on streaming.
Comment 72 Brallan Aguilar 2013-05-18 09:03:06 UTC
I have this problem too with KDE 4.10.3. My laptop has a volume control wheel and when I want to lower or raise the volume suddenly the volume does not change until later (as if the volume control to freezes, KMix was consuming 50% of CPU). Recently I change to Plastique theme and I tried the volume up and down instantly and I had no problem (KMix used 5% of CPU).
Comment 73 Rael Gugelmin Cunha 2013-05-18 12:13:14 UTC
Just recorded a screencast: http://www.screencast.com/t/WmLPLNuLarL

See: I started a stream playback on Amarok. Then I resume double clicking on the Streaming track (cause there is a bug on Amarok too to resume streaming).

Before someone point to Amarok, the same (KMix increasing RAM usage) happening using Clementine and others.

Not easy days to listening streaming on KDE, right?
Comment 74 Hugo Pereira Da Costa 2013-05-18 12:20:57 UTC
@Rael,
sorry, these posts are not helping.
No extra information is provided, just descriptions of your everyday life, your switching to somethings else, etc. This will not help the bug getting fixed sooner (pretty much the contrary in fact).  Bug reports are not forum discussions. Comments 68, 70, 71, 73 belong to forums. Not here. 

Please have patience ...
Comment 75 Hugo Pereira Da Costa 2013-05-18 12:25:25 UTC
PS: 
if you want to bring more information to help getting this fixed, valgrind logs are more helpfull than screencasts.
Comment 76 Rael Gugelmin Cunha 2013-05-18 13:00:45 UTC
Sorry Hugo.

How can I remove them? Can you remove them (please)?
Comment 77 Rael Gugelmin Cunha 2013-05-19 21:31:30 UTC
Created attachment 79967 [details]
Kmix running with valgrind

Hugo, trying to redeem myself.

I searched about valgrind and started with: valgrind --tool=memcheck --num-callers=40 kmix --nofork &>/tmp/kmixlog.txt
Comment 78 Jiri Slaby 2013-05-20 09:33:32 UTC
(In reply to comment #77)
> Created attachment 79967 [details]
> Kmix running with valgrind

This is useless.

You don't have debugging symbols installed and your didn't run it as the guys above, with leak check yes/full. Anyway, I don't think we need more than the attached valgrind analyses above as there can be nicely seen where the leaks stem from...
Comment 79 Griwes 2013-06-22 21:11:27 UTC
(In reply to comment #53)
> (In reply to comment #52)
> 
> Take it easy.  Maybe he once wrote a 50-liner without memory leaks... :)
> 

If KDE properly used smart pointers and shit, such memory leaks would be *EASILY* avoidable. But not, let's keep using broken ways of manual memory management... 

Don't get me wrong, KDE is awesome, but when it comes to quality and style of the code base, it's a pile of poo.
Comment 80 Hugo Pereira Da Costa 2013-06-24 16:36:38 UTC
Some progress.
With latest kmix, running valgrind, I found nothing suspicious neither on kmix side nor on oxygen side. Now, investigating further it appears that the memory increase is indeed related to oxygen, AnimationData, though not being a leak. 
What I've found is that calling deleteLater on the animation objects (and the underlying QProperties) result in the objects not being deleted untill at when kmix quits, as opposed to immediate deletion. Objects created for every new sound would then accumulate, resulting in the increase.

To be honest, I do not know enough of QObject::deleteLater() with respect to simple delete object; and why it results in the above behavior. 

I'll attach patch to kde-workspace in the following comment for kmix devs to test and confirm; and will investigate further on my side: there is a chance that calling delete directly is actually dangerous, and might result in crashes elsewhere ... 

If somebody from kmix devs have some insight/experience on when to use (and when not) QObject::deleteLater(), advice would be very appreciated.

Hugo
Comment 81 Hugo Pereira Da Costa 2013-06-24 16:38:46 UTC
Created attachment 80749 [details]
applies to master (or KDE/4.10) branch.

use delete object, rather than object->deleteLater, when unregistering animations associated to a given widget.
Comment 82 Hugo Pereira Da Costa 2013-06-24 17:06:24 UTC
... For the record, the use of ->deleteLater() was first introduced to solve bug 247827
https://bugs.kde.org/show_bug.cgi?id=247827
(and duplicates)
Comment 83 TOM Harrison 2013-06-25 11:46:14 UTC
i have try the attach that change the oxygen.
it seems it solve that problem.
i will try more.
Comment 84 Hugo Pereira Da Costa 2013-06-25 12:00:16 UTC
@l12436
Thanks a lot for testing the patch and reporting.
Would help If you could run with it for some time, in case it produces regressions (in which case, don't hesitate to report back). 
Looking back at the old bugs, I'm not 100% convinced that the 'cure' was actually fixing the problem, but rather workaround it, with the problem actually being in Qt, hopefully getting fixed in more recent versions. (I cannot - and in fact never could- reproduce the crash from the bugs  above)
If all goes well, I'll commit the change in a couple of days/weeks (so that it lands in kde 4.11)
Comment 85 TOM Harrison 2013-06-25 12:53:38 UTC
i hope so. if the 4.10.5 did not contain this fix, i need to compiler again or use the old binary cod  to fix this problem
Comment 86 TOM Harrison 2013-06-25 12:53:58 UTC
i hope so. if the 4.10.5 did not contain this fix, i need to compiler again or use the old binary code to fix this problem
Comment 87 Rael Gugelmin Cunha 2013-06-26 19:02:22 UTC
Hugo, do you think this bug, https://bugs.kde.org/show_bug.cgi?id=314919, has any relation with current one?
Comment 88 Hugo Pereira Da Costa 2013-06-26 19:29:22 UTC
@Rael,
don't think so: here the 'leak' was related to QObject, so direct memory, and not X allocation, unlike for the other bug.
Comment 89 TOM Harrison 2013-06-27 14:19:19 UTC
i am trying th lastest beta version of kde.
the oxygen fix is not comment yet, so i just can recompile again
Comment 90 Hugo Pereira Da Costa 2013-06-27 14:27:40 UTC
@l12436
no not committed yet. I want to test some more whether the crash that the original change (the one that causes the 'leak') re-occurs.
I'm planning to commit the change in a week or so, in case nothing wrong shows up.
Sorry for the delay.
Comment 91 TOM Harrison 2013-06-27 14:49:45 UTC
according to my testing with amarok and clementine.
it seems did not re-occur. 
although i have seen it memory increase from 23.4MB to 24.4.
but that just increase once.
so i think it normal.
i will continue see it memory usage.

P.S. 4.10.80 sure has a little bug, but it speed is faster than 4.10. I am thinking whether I need to return to 4.10 or not. and the 4.10.80 cause the smooth-task-2 could not work.
Comment 92 Martin Holec 2013-06-27 16:05:54 UTC
Hugo, you can reproduce this by visiting http://www.listentobitcoin.com/ and keep it running for cca 2 hours. Like described in dupe #318204
Comment 93 Hugo Pereira Da Costa 2013-06-27 16:14:08 UTC
@Martin,
sorry, won't do that.
(I usually work with valgrind logs).
Now, what's described in bug #318204 sounds pretty similar to what can be achieved with paplay (comment #42), which is what I used to track down the issue. 
So most likely the fix above also fixes what you suggest.
Comment 94 Hugo Pereira Da Costa 2013-07-01 08:31:11 UTC
Git commit b7836534cb125f9c94f29a039b5dc8597300d321 by Hugo Pereira Da Costa.
Committed on 24/06/2013 at 16:28.
Pushed by hpereiradacosta into branch 'master'.

delete animation data directly rather than using deleteLater, which results in all objects being deleted at exit, thus effectively appearing as a memory leak

M  +1    -1    kstyles/oxygen/animations/oxygendatamap.h

http://commits.kde.org/kde-workspace/b7836534cb125f9c94f29a039b5dc8597300d321
Comment 95 Hugo Pereira Da Costa 2013-07-01 08:32:00 UTC
Git commit 984b9c4ad6b35fa07019e4d4d083e07749482a29 by Hugo Pereira Da Costa.
Committed on 24/06/2013 at 16:28.
Pushed by hpereiradacosta into branch 'KDE/4.10'.

delete animation data directly rather than using deleteLater, which results in all objects being deleted at exit, thus effectively appearing as a memory leak

M  +1    -1    kstyles/oxygen/animations/oxygendatamap.h

http://commits.kde.org/kde-workspace/984b9c4ad6b35fa07019e4d4d083e07749482a29
Comment 96 Hugo Pereira Da Costa 2013-07-01 08:32:37 UTC
patch is committed, so closing.
Comment 97 TOM Harrison 2013-07-01 08:38:25 UTC
so it will appear on the next 4.10.5 and 4.11 RC1 ?
Comment 98 Jekyll Wu 2013-07-01 09:13:39 UTC
probably a little late for 4.10.5 ...
Comment 99 TOM Harrison 2013-07-01 09:26:40 UTC
that is OK.
i am using the 4.10.90, 4.11 beta version.
so i believe it will fix in 4.11.
Comment 100 Rex Dieter 2013-07-01 13:13:45 UTC
so, some not-good news... some discussion on irc in #kde-multimedia lead to a conclusion that the problem is likely still present (in kmix).

<apachelogger> bug #309464 is the result of bad threading btw
<rdieter> oh the lulz
<apachelogger> some foreign thread (PA?) is probably being dragged throughout kmix because Qthread doesn't know it's a foreign thread
<apachelogger> so deleteLater does absolute nothing because there is no eventloop present
<apachelogger> well, no qeventloop anyway ^^
<rdieter> apachelogger: fun, does that mean after switch deleteLater->delete, things may get crashy again?
<apachelogger> rdieter: not unlikely
<apachelogger> I fixed the same problem some 2 years ago, at least back then threads were being pushed through which I solved by using queued connections
<apachelogger> in my experience, assuming qthread will do the right thing with non-qt threads goes wrong 50% of the time
<apachelogger> e.g. with vlc you also get thread pollution if you don't force stuff to interact queued anyway
<apachelogger> rdieter: I don't think delete in oxygen is the correct solution here, it's just moving the fallout out of oxygen
<apachelogger> the problem that causes deleteLater to not work still remains present
<rdieter> makes sense :(    I suppose that bug should be re-opened then?
<apachelogger> yeah

So, here we are.
Comment 101 TOM Harrison 2013-07-01 13:31:19 UTC
so the memory leak problem is still can not commit :(
i think i need to save this patch for l long time.
Comment 102 Harald Sitter 2013-07-01 14:21:30 UTC
totally shitty regression

original fix:
http://quickgit.kde.org/?p=kmix.git&a=commit&h=5ed2ab021f2cd4978bc91727b3c7d2eb168bcbbe

regression:
http://quickgit.kde.org/?p=kmix.git&a=blobdiff&h=120c088436fce4429c2d8b285a08aac1915435f0&hp=e9dedd33a00fbb1a8bd99a6694e9f3e7d836ef68&hb=c565cfe6d38d0f7e9707500b3365c6185222cb07&f=backends%2Fmixer_pulse.cpp

line 75 shows why this is a regression:
http://quickgit.kde.org/?p=kmix.git&a=blob&h=3e338940349fe50da92c56295c8092600691b8e1&hb=6c9d6eee30be2038ddc31c35dc9659da8d0dad50&f=core%2FControlManager.cpp

ControlManager needs to use a queued connection, using an explicit direct connection there is even crappier than what had originally caused the leak in 2011 (which was an implicit direct connection - there at least was slim chance of qt doing the right thing).....
Comment 103 Hugo Pereira Da Costa 2013-07-01 17:07:42 UTC
@Rex
Thanks for the cut'n'npaste, very informative.
It does seem to explain why the deleteLater issue in oxygen would show up in kmix and not 'all over the place' (think: kwin), at least not as far as I can tell. 
What do you guys suggest ? That I revert the Oxygen change, since this is just a (possibly crashy) workaround and not a fix to the root of the issue ? 
To be honest I am a bit unconfortable with the use of delete instead of delete later, in view of bug 247827 and duplicate ...

Hugo
Comment 104 Harald Sitter 2013-07-01 18:41:44 UTC
(In reply to comment #103)
> What do you guys suggest ? That I revert the Oxygen change, since this is
> just a (possibly crashy) workaround and not a fix to the root of the issue ? 

Yes.

deleteLater misbehaves because there is no qeventloop present [1]. for all intents and purposes you could probably prevent/detect this internally by 

if I recall correctly deleteLater pretty much will do nothing more than insert the delete action in the eventloop of the deletee such that it will be executed once the stack unwinds (i.e. control returns). essentially what happens is that kmix gets a callback from PA with new/removed sink information, then kmix goes through a direct call chain to create/delete qwidgets (still in the PA thread). then inside oxygen you create objects and these objects now do not have an associated qthread because it's still inside the PA callback thread (which is obvious enough no qthread) and therefore no eventloop is present. finally when deletelater is called on those objects it will do nothing because there is no eventloop to add the deferred deletion to.

[1] http://qt-project.org/doc/qt-5.0/qtcore/qobject.html#deleteLater
Comment 105 Hugo Pereira Da Costa 2013-07-01 18:53:10 UTC
@Harald,
Thanks ! clear enough. 
Reverting the oxygen change then. Sorry for the false hope.
Note to users that suffer the issue and are eagerly waiting for the proper fix.
- in the meanwhile you can apply the patch to oxygen above and compile your own version
- if you are unwilling to patch and compile the full kde-workspace, you can try build oxygen-transparent from source (see in kde-looks). That should get you pretty much the same, but standalone. the patch should apply there just fine too.
Comment 106 Hugo Pereira Da Costa 2013-07-01 18:57:41 UTC
Git commit fbc7042a6c00562f62b3f1defb4ae9132da3cbbf by Hugo Pereira Da Costa.
Committed on 01/07/2013 at 18:57.
Pushed by hpereiradacosta into branch 'KDE/4.10'.

Revert "delete animation data directly rather than using deleteLater, which results in all objects being deleted at exit, thus effectively appearing as a memory leak"

This reverts commit 984b9c4ad6b35fa07019e4d4d083e07749482a29.

M  +1    -1    kstyles/oxygen/animations/oxygendatamap.h

http://commits.kde.org/kde-workspace/fbc7042a6c00562f62b3f1defb4ae9132da3cbbf
Comment 107 Hugo Pereira Da Costa 2013-07-01 18:57:42 UTC
Git commit 9bd69b20f143eae51930f52b871146f45988aec8 by Hugo Pereira Da Costa.
Committed on 01/07/2013 at 18:57.
Pushed by hpereiradacosta into branch 'master'.

Revert "delete animation data directly rather than using deleteLater, which results in all objects being deleted at exit, thus effectively appearing as a memory leak"

This reverts commit b7836534cb125f9c94f29a039b5dc8597300d321.

M  +1    -1    kstyles/oxygen/animations/oxygendatamap.h

http://commits.kde.org/kde-workspace/9bd69b20f143eae51930f52b871146f45988aec8
Comment 108 Christian Esken 2013-07-01 22:44:03 UTC
Harald, I trust your comment 104, and thus I am going to "revert" the direct call. I really was not aware that a PulseAudio thread calls the ControlManager::instance().announce(). So I am going to revert back to invokeMethod(), more precisely:
 - do the invokeMethod() to a backend internal slot
 - The slot does all the synchronous announce() stuff.
And before you ask, I can and will not change that announce() thing to do asynchronous calls/signals/emits. :)
Comment 109 Christian Esken 2013-07-01 22:47:20 UTC
Git commit 6edddf7c8e92bb499cb60fdee53622cab326f334 by Christian Esken.
Committed on 01/07/2013 at 22:44.
Pushed by esken into branch 'master'.

Revert my direct use of ControlManager::instance().announce(). PA actually did call it in its own thread and so in the end we have a non-GUI thread calling GUI code. Use invokeMethod() again.

M  +47   -0    backends/mixer_pulse.cpp
M  +7    -0    backends/mixer_pulse.h

http://commits.kde.org/kmix/6edddf7c8e92bb499cb60fdee53622cab326f334
Comment 110 TOM Harrison 2013-07-02 02:24:56 UTC
i have tried the change of mixer_pulse
and it seems solve the memory leak, too.
i will tried more that if is solved or not.
Comment 111 Mircea Kitsune 2013-07-08 09:18:39 UTC
I don't have 4.11.0 yet (currently at 4.10.3) but this bug has been bothering me since many KDE versions. Changing the volume or muting / unmuting sound with the keyboard media keys seems to be the trigger, likely due to the volume widget appearing on the screen when you do so. As it leaks, the volume keys also become very slow and barely even work any more. Restarting kmix each time fixes it at least.
Comment 112 TOM Harrison 2013-07-08 09:30:58 UTC
(In reply to comment #111)
> I don't have 4.11.0 yet (currently at 4.10.3) but this bug has been
> bothering me since many KDE versions. Changing the volume or muting /
> unmuting sound with the keyboard media keys seems to be the trigger, likely
> due to the volume widget appearing on the screen when you do so. As it
> leaks, the volume keys also become very slow and barely even work any more.
> Restarting kmix each time fixes it at least.
Comment 109 
this patch could fix the kmix memory leak.
you can build it on your kde.
Comment 113 Christian Esken 2013-07-17 23:16:20 UTC
Git commit ee338c55f68c716b622acd2a60972eac32318561 by Christian Esken.
Committed on 17/07/2013 at 23:12.
Pushed by esken into branch 'master'.

Remove some memory leaks. Mainly cleanup for shutdown, but also for (dynamic) controls. Makes valgrind output easier to inspect for relevant leaks.

M  +8    -0    apps/kmix.cpp
M  +20   -9    backends/mixer_alsa9.cpp
M  +8    -1    backends/mixer_mpris2.cpp
M  +17   -1    gui/guiprofile.cpp
M  +2    -0    gui/guiprofile.h

http://commits.kde.org/kmix/ee338c55f68c716b622acd2a60972eac32318561
Comment 114 TOM Harrison 2013-07-18 01:34:08 UTC
after apply the new patch. 
the pulseaudio is missing.
could you checked?
and this patch is for the newest kmix source?
Comment 115 TOM Harrison 2013-07-18 01:42:15 UTC
my fault.
i see my pulse dev has been delete.
Comment 116 Christoph Feck 2013-07-20 12:16:32 UTC
Can someone confirm the commit from comment #109 fixed this issue? Please try KDE 4.10.95 (4.11 RC1 release candidate) to test this.
Comment 117 TOM Harrison 2013-07-20 12:46:14 UTC
Git commit 6edddf7c8e92bb499cb60fdee53622cab326f334 by Christian Esken.
Committed on 01/07/2013 at 22:44.
Pushed by esken into branch 'master'.

Revert my direct use of ControlManager::instance().announce(). PA actually did call it in its own thread and so in the end we have a non-GUI thread calling GUI code. Use invokeMethod() again.

M  +47   -0    backends/mixer_pulse.cpp
M  +7    -0    backends/mixer_pulse.h

http://commits.kde.org/kmix/6edddf7c8e92bb499cb60fdee53622cab326f334
this patch i have used. seems fix the problem too.
and the next patch i just use four patch.
because some of the code is different.
Comment 118 Vladimir 2013-07-21 09:18:21 UTC
KDE 4.11 RC1 works perfectly for me.
Comment 119 TOM Harrison 2013-07-23 15:10:53 UTC
asking one thing is this bug will fix in kde 4.11 RC2?
Comment 120 Rex Dieter 2013-07-23 15:17:03 UTC
yes (fix was in 4.11rc1, aka 4.10.95 in fact)
Comment 121 TOM Harrison 2013-07-23 16:01:42 UTC
i am still in 4.10.90.
is that release is release in kde beta ppa ?
Comment 122 Sol 2013-08-02 15:23:23 UTC
For those that are following and testing this, streaming also makes Kmix leak heavily. For example, I was watching a couple of twitch streams, and about 10 hours latter Kmix was using more than 3Gb of ram. I'm still on  4.10.5 though, waiting for 4.10.95 to hit Kubuntu so I can update.

kmix --version
Qt: 4.8.4
KDE Development Platform: 4.10.5
KMix: 4.3
Comment 123 TOM Harrison 2013-08-03 01:07:48 UTC
(In reply to comment #122)
> For those that are following and testing this, streaming also makes Kmix
> leak heavily. For example, I was watching a couple of twitch streams, and
> about 10 hours latter Kmix was using more than 3Gb of ram. I'm still on 
> 4.10.5 though, waiting for 4.10.95 to hit Kubuntu so I can update.
> 
> kmix --version
> Qt: 4.8.4
> KDE Development Platform: 4.10.5
> KMix: 4.3

this is solved in 4.10.95 and that version is beta version.
you can update by add the ppa
Comment 124 Christian Esken 2013-08-14 23:30:15 UTC
Has likely the same reason as bug 415473. Thus should be fixed with KMix 4.4 / KDE 4.11. Thus I will close this bug report. Should you have the same issue in KDE4.11, please report it again.
Comment 125 Christoph Feck 2013-10-02 23:48:40 UTC
*** Bug 316141 has been marked as a duplicate of this bug. ***