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
Created attachment 74954 [details] kmix memory usage shown in ksysguard
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.
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.
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
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.
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.
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
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.
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).
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
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
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).
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.
@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.
Created attachment 76090 [details] Fix the small memory leak caused by unnecessarily creating object on heap
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.
(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.
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)
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
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
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
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
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
*** Bug 312891 has been marked as a duplicate of this bug. ***
i have make the newest vesion of kmix. and it seems it did not solve already. will it fix in the next RC ?
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).
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 .
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.
It seems it's a bug in PA, when I disabled it, kmix uses the same amount of memory.
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/
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.
(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.
Created attachment 77523 [details] memory leak log created by valgrind
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
and the valgrind program is telled by https://bugs.freedesktop.org/show_bug.cgi?id=61336 this bug report.
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
Created attachment 77526 [details] kmix error create by valgrind
Created attachment 77528 [details] kmix memory leak both record and playback.
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.
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,
FWIW I'm still seeing this with 4.10. kmix just had 500M of RSS before I killed that...
Nicely reproducible with: while :; do paplay /usr/share/sounds/KDE_Beep_Ahem.wav ; sleep 1; done
(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!
actually when i use the Audacity or amaork. there also has memory leak.
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.
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.
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.
Well... when i play Age of Empires II - Conquerors with wine, kmix up to 470MB in 30 mins... Looks like a very critical bug.
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.
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.
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.
(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.
(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?
(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.
*** Bug 318204 has been marked as a duplicate of this bug. ***
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?
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.
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 ?
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).
the pulseaudio website say his program did not has memory leak. so he say the memory leak is caused by kmix
*** Bug 318552 has been marked as a duplicate of this bug. ***
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)
Yes, plastik seems to work. But I hate it. Is there any other themes that work?
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. >
I'm getting 500-750MB memory usage by kmix.
updating summary to match findings so far (pulseaudio + oxygen + media track changes)
Add oxygen maintainer per discussions since comment #57
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.
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
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.
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.
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).
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?
@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 ...
PS: if you want to bring more information to help getting this fixed, valgrind logs are more helpfull than screencasts.
Sorry Hugo. How can I remove them? Can you remove them (please)?
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
(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...
(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.
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
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.
... 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)
i have try the attach that change the oxygen. it seems it solve that problem. i will try more.
@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)
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
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
Hugo, do you think this bug, https://bugs.kde.org/show_bug.cgi?id=314919, has any relation with current one?
@Rael, don't think so: here the 'leak' was related to QObject, so direct memory, and not X allocation, unlike for the other bug.
i am trying th lastest beta version of kde. the oxygen fix is not comment yet, so i just can recompile again
@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.
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.
Hugo, you can reproduce this by visiting http://www.listentobitcoin.com/ and keep it running for cca 2 hours. Like described in dupe #318204
@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.
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
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
patch is committed, so closing.
so it will appear on the next 4.10.5 and 4.11 RC1 ?
probably a little late for 4.10.5 ...
that is OK. i am using the 4.10.90, 4.11 beta version. so i believe it will fix in 4.11.
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.
so the memory leak problem is still can not commit :( i think i need to save this patch for l long time.
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).....
@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
(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
@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.
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
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
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. :)
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
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.
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.
(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.
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
after apply the new patch. the pulseaudio is missing. could you checked? and this patch is for the newest kmix source?
my fault. i see my pulse dev has been delete.
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.
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.
KDE 4.11 RC1 works perfectly for me.
asking one thing is this bug will fix in kde 4.11 RC2?
yes (fix was in 4.11rc1, aka 4.10.95 in fact)
i am still in 4.10.90. is that release is release in kde beta ppa ?
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
(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
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.
*** Bug 316141 has been marked as a duplicate of this bug. ***