Bug 237239 - Kmix memory leak
Summary: Kmix memory leak
Status: RESOLVED FIXED
Alias: None
Product: kmix
Classification: Unclassified
Component: Backend: Pulseaudio (show other bugs)
Version: unspecified
Platform: Mandriva RPMs Linux
: NOR major with 120 votes (vote)
Target Milestone: ---
Assignee: Colin Guthrie
URL:
Keywords:
: 257915 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-11 13:32 UTC by fabiomargarido
Modified: 2011-12-10 01:11 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
"valgrind --tool=massif --time-unit=ms --max-snapshots=1000 kmix" while running java game (686.88 KB, application/x-gzip)
2011-03-23 00:39 UTC, Oliver Henshaw
Details
"ms_print massif.out.21545 > msprint.out.2154; massdiff.py msprint.out.21545 18 645" output (6.95 KB, application/x-gzip)
2011-03-23 00:43 UTC, Oliver Henshaw
Details
Screenshot showing KMix’ interface and its RAM usage (98.76 KB, image/png)
2011-03-25 12:47 UTC, Panagiotis Papadopoulos
Details
script to demonstrate kmix memory growth using paplay and smem (283 bytes, text/plain)
2011-04-08 18:42 UTC, Oliver Henshaw
Details
results from kmix-test.sh (2.00 KB, text/plain)
2011-04-08 18:50 UTC, Oliver Henshaw
Details
My results showing no change :s (1.84 KB, text/plain)
2011-06-02 14:31 UTC, Colin Guthrie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fabiomargarido 2010-05-11 13:32:35 UTC
Version:            (using KDE 4.4.2)
OS:                Linux
Installed from:    Mandriva RPMs

After leaving my machine on for a few days, kmix always shows a huge memory use. I've seen it using from 23 to 56% of my 2 GBs.
I've run it under valgrind for a few hours and A LOT of memory loss records were generated (in this particular example, 11199), so I can't post the entire report here. But at least for me it's always reproducible.
A lot of the debugging data points to font-related stuff and oxygen, so some base library, and not kmix, may be at fault here. Which would be strange, since it's the only application in my system which exhibits this behavior.
Please let me know if I can provide any further info.
Here are the final records which show the biggest memory leaks:

(...)
==25606== 27,840 bytes in 290 blocks are possibly lost in loss record 11,160 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FD51C3: QVectorData::allocate(int, int) (qvector.cpp:67)
==25606==    by 0x509A683: QVector<QObjectPrivate::ConnectionList>::realloc(int, int) (qvector.h:391)
==25606==    by 0x5093117: QObjectPrivate::addConnection(int, QObjectPrivate::Connection*) (qvector.h:330)
==25606==    by 0x509455D: QMetaObjectPrivate::connect(QObject const*, int, QObject const*, int, int, int*) (qobject.cpp:2926)
==25606==    by 0x5094C7C: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2599)
==25606==    by 0x91443DC: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9144CE5: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9151725: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142BDE: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606== 
==25606== 28,768 bytes in 1 blocks are possibly lost in loss record 11,161 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FD51C3: QVectorData::allocate(int, int) (qvector.cpp:67)
==25606==    by 0x5539743: QVector<QFontEngine::KernPair>::realloc(int, int) (qvector.h:391)
==25606==    by 0x5534573: QFontEngine::loadKerningPairs(QFixed) (qvector.h:547)
==25606==    by 0x560A80A: QFontEngineFT::doKerning(QGlyphLayout*, QFlags<QTextEngine::ShaperFlag>) const (qfontengine_ft.cpp:1381)
==25606==    by 0x55365E1: QFontEngineMulti::doKerning(QGlyphLayout*, QFlags<QTextEngine::ShaperFlag>) const (qfontengine.cpp:1536)
==25606==    by 0x556A7E0: QTextEngine::shapeTextWithHarfbuzz(int) const (qtextengine.cpp:1265)
==25606==    by 0x91FC2E7: ???
==25606== 
==25606== 28,881 bytes in 2 blocks are possibly lost in loss record 11,162 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7B47C: QByteArray::QByteArray(char const*, int) (qbytearray.cpp:1289)
==25606==    by 0x4F7B577: QByteArray::mid(int, int) const (qbytearray.cpp:2591)
==25606==    by 0xFFFFFFFE: ???
==25606== 
==25606== 28,968 bytes in 2,414 blocks are possibly lost in loss record 11,163 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x508629C: QList<QPostEvent>::append(QPostEvent const&) (qlist.h:351)
==25606==    by 0x5084911: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (qcoreapplication.cpp:1319)
==25606==    by 0x5084ADB: QCoreApplication::sendPostedEvents(QObject*, int) (qcoreapplication.cpp:1238)
==25606==    by 0x50AEFDC: postEventSourceDispatch(_GSource*, int (*)(void*), void*) (qcoreapplication.h:220)
==25606==    by 0x4B7169D: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.2304.0)
==25606==    by 0x4B75387: ??? (in /usr/lib/libglib-2.0.so.0.2304.0)
==25606==    by 0x4B7554D: g_main_context_iteration (in /usr/lib/libglib-2.0.so.0.2304.0)
==25606==    by 0x50AEAC0: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:412)
==25606==    by 0x5397DB9: QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qguieventdispatcher_glib.cpp:204)
==25606==    by 0x50805EC: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:149)
==25606==    by 0x51999C3: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 30,814 bytes in 991 blocks are possibly lost in loss record 11,168 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7B47C: QByteArray::QByteArray(char const*, int) (qbytearray.cpp:1289)
==25606==    by 0x4C881CF: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>, bool) (bufferfragment_p.h:167)
==25606==    by 0x4C89368: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>) (kconfigini.cpp:66)
==25606==    by 0x4C71B8A: KConfigPrivate::parseConfigFiles() (kconfig.cpp:516)
==25606==    by 0x4C720F0: KConfig::reparseConfiguration() (kconfig.cpp:453)
==25606==    by 0x4C72ECB: KConfig::KConfig(KComponentData const&, QString const&, QFlags<KConfig::OpenFlag>, char const*) (kconfig.cpp:171)
==25606==    by 0x4C8C4D5: KSharedConfig::KSharedConfig(KComponentData const&, QString const&, QFlags<KConfig::OpenFlag>, char const*) (ksharedconfig.cpp:64)
==25606==    by 0x4C8C6FD: KSharedConfig::openConfig(KComponentData const&, QString const&, QFlags<KConfig::OpenFlag>, char const*) (ksharedconfig.cpp:56)
==25606==    by 0x4C8C8CC: KSharedConfig::openConfig(QString const&, QFlags<KConfig::OpenFlag>, char const*) (ksharedconfig.cpp:35)
==25606==    by 0x195D9577: ???
==25606== 
==25606== 32,400 bytes in 150 blocks are possibly lost in loss record 11,169 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x4F61AB9: QPropertyAnimation::QPropertyAnimation(QObject*) (qpropertyanimation.cpp:148)
==25606==    by 0x9144C8E: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x91565C7: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142B98: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x53385D8: QWidget::event(QEvent*) (qwidget.cpp:8064)
==25606==    by 0x56F271F: QAbstractButton::event(QEvent*) (qabstractbutton.cpp:1080)
==25606==    by 0x570B1B7: QCheckBox::event(QEvent*) (qcheckbox.cpp:385)
==25606==    by 0x52D772B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4298)
==25606==    by 0x52DE607: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4263)
==25606== 
==25606== 32,400 bytes in 150 blocks are possibly lost in loss record 11,170 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x4F61AB9: QPropertyAnimation::QPropertyAnimation(QObject*) (qpropertyanimation.cpp:148)
==25606==    by 0x9144C8E: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9156881: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142B98: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x53385D8: QWidget::event(QEvent*) (qwidget.cpp:8064)
==25606==    by 0x56F271F: QAbstractButton::event(QEvent*) (qabstractbutton.cpp:1080)
==25606==    by 0x570B1B7: QCheckBox::event(QEvent*) (qcheckbox.cpp:385)
==25606==    by 0x52D772B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4298)
==25606==    by 0x52DE607: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4263)
==25606== 
==25606== 32,616 bytes in 151 blocks are possibly lost in loss record 11,171 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x4F61AB9: QPropertyAnimation::QPropertyAnimation(QObject*) (qpropertyanimation.cpp:148)
==25606==    by 0x9145703: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9149845: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142BC6: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x53385D8: QWidget::event(QEvent*) (qwidget.cpp:8064)
==25606==    by 0x5792E2B: QMenu::event(QEvent*) (qmenu.cpp:2415)
==25606==    by 0x52D772B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4298)
==25606==    by 0x52DE607: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4263)
==25606== 
==25606== 32,616 bytes in 151 blocks are possibly lost in loss record 11,172 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x4F61AB9: QPropertyAnimation::QPropertyAnimation(QObject*) (qpropertyanimation.cpp:148)
==25606==    by 0x9145746: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9149845: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142BC6: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x53385D8: QWidget::event(QEvent*) (qwidget.cpp:8064)
==25606==    by 0x5792E2B: QMenu::event(QEvent*) (qmenu.cpp:2415)
==25606==    by 0x52D772B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4298)
==25606==    by 0x52DE607: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4263)
==25606== 
==25606== 32,768 bytes in 1 blocks are possibly lost in loss record 11,175 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7C09D: QByteArray::realloc(int) (qbytearray.cpp:1411)
==25606==    by 0x4F7C5B6: QByteArray::resize(int) (qbytearray.cpp:1379)
==25606==    by 0x5011CAC: QIODevice::read(char*, long long) (qringbuffer_p.h:158)
==25606==    by 0x4568346: KPixmapCache::Private::indexDevice() (kpixmapcache.cpp:563)
==25606==    by 0x4568FA9: KPixmapCache::discard() (kpixmapcache.cpp:1292)
==25606==    by 0x44A13C2: KIconCache::find(QString const&, QPixmap&, QString*) (kiconcache.cpp:82)
==25606==    by 0x4493E78: KIconLoader::loadIcon(QString const&, KIconLoader::Group, int, int, QStringList const&, QString*, bool) const (kiconloader.cpp:1092)
==25606==    by 0x14BC180F: ???
==25606== 
==25606== 32,768 bytes in 1 blocks are possibly lost in loss record 11,176 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7C09D: QByteArray::realloc(int) (qbytearray.cpp:1411)
==25606==    by 0x4F7C5B6: QByteArray::resize(int) (qbytearray.cpp:1379)
==25606==    by 0x5011CAC: QIODevice::read(char*, long long) (qringbuffer_p.h:158)
==25606==    by 0x4568346: KPixmapCache::Private::indexDevice() (kpixmapcache.cpp:563)
==25606==    by 0x4568FA9: KPixmapCache::discard() (kpixmapcache.cpp:1292)
==25606==    by 0x44A13C2: KIconCache::find(QString const&, QPixmap&, QString*) (kiconcache.cpp:82)
==25606==    by 0x4493E78: KIconLoader::loadIcon(QString const&, KIconLoader::Group, int, int, QStringList const&, QString*, bool) const (kiconloader.cpp:1092)
==25606==    by 0x19BF8417: ???
==25606== 
==25606== 36,602 bytes in 1,055 blocks are possibly lost in loss record 11,177 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7B47C: QByteArray::QByteArray(char const*, int) (qbytearray.cpp:1289)
==25606==    by 0x4C881ED: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>, bool) (bufferfragment_p.h:167)
==25606==    by 0x4C89368: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>) (kconfigini.cpp:66)
==25606==    by 0x5199467: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 41,862 bytes in 302 blocks are possibly lost in loss record 11,178 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FC573E: QString::realloc(int) (qstring.cpp:1219)
==25606==    by 0x503E23B: QSettingsPrivate::iniUnescapedKey(QByteArray const&, int, int, QString&) (qstring.h:870)
==25606==    by 0x5040320: QConfFileSettingsPrivate::readIniSection(QSettingsKey const&, QByteArray const&, QMap<QSettingsKey, QVariant>*, QTextCodec*) (qsettings.cpp:1822)
==25606==    by 0x504495C: QConfFileSettingsPrivate::ensureSectionParsed(QConfFile*, QSettingsKey const&) const (qsettings.cpp:2005)
==25606==    by 0x5044A90: QConfFileSettingsPrivate::get(QString const&, QVariant*) const (qsettings.cpp:1303)
==25606==    by 0x503CBE3: QSettings::value(QString const&, QVariant const&) const (qsettings.cpp:3352)
==25606== 
==25606== 42,991 bytes in 1,408 blocks are possibly lost in loss record 11,179 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4F7B47C: QByteArray::QByteArray(char const*, int) (qbytearray.cpp:1289)
==25606==    by 0x4C881CF: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>, bool) (bufferfragment_p.h:167)
==25606==    by 0x4C89368: KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>) (kconfigini.cpp:66)
==25606==    by 0x5199467: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 44,160 bytes in 460 blocks are possibly lost in loss record 11,180 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x40249A6: realloc (vg_replace_malloc.c:476)
==25606==    by 0x5546FE1: QtFontStyle::pixelSize(unsigned short, bool) (qfontdatabase.cpp:290)
==25606==    by 0x554AE75: initializeDb() (qfontdatabase_x11.cpp:1374)
==25606==    by 0x5552ABF: QFontDatabase::load(QFontPrivate const*, int) (qfontdatabase_x11.cpp:1954)
==25606==    by 0x5199467: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 51,936 bytes in 1,082 blocks are possibly lost in loss record 11,181 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x40249A6: realloc (vg_replace_malloc.c:476)
==25606==    by 0x55470D8: QtFontSize::encodingID(int, unsigned int, unsigned int, unsigned int, unsigned int, bool) (qfontdatabase.cpp:178)
==25606==    by 0x554B82B: initializeDb() (qfontdatabase_x11.cpp:1168)
==25606==    by 0x5552ABF: QFontDatabase::load(QFontPrivate const*, int) (qfontdatabase_x11.cpp:1954)
==25606==    by 0x5199467: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 55,296 bytes in 576 blocks are possibly lost in loss record 11,184 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x40249A6: realloc (vg_replace_malloc.c:476)
==25606==    by 0x5546FE1: QtFontStyle::pixelSize(unsigned short, bool) (qfontdatabase.cpp:290)
==25606==    by 0x554B7F3: initializeDb() (qfontdatabase_x11.cpp:1162)
==25606==    by 0x5552ABF: QFontDatabase::load(QFontPrivate const*, int) (qfontdatabase_x11.cpp:1954)
==25606==    by 0x5199467: ??? (in /usr/lib/libQtCore.so.4.6.1)
==25606== 
==25606== 60,760 bytes in 884 blocks are possibly lost in loss record 11,188 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FC573E: QString::realloc(int) (qstring.cpp:1219)
==25606==    by 0x4FC5F35: QString::resize(int) (qstring.cpp:1155)
==25606==    by 0x503FDE7: QSettingsPrivate::iniUnescapedStringList(QByteArray const&, int, int, QString&, QStringList&, QTextCodec*) (qsettings.cpp:896)
==25606==    by 0x50403CA: QConfFileSettingsPrivate::readIniSection(QSettingsKey const&, QByteArray const&, QMap<QSettingsKey, QVariant>*, QTextCodec*) (qsettings.cpp:1827)
==25606==    by 0x504495C: QConfFileSettingsPrivate::ensureSectionParsed(QConfFile*, QSettingsKey const&) const (qsettings.cpp:2005)
==25606==    by 0x5044A90: QConfFileSettingsPrivate::get(QString const&, QVariant*) const (qsettings.cpp:1303)
==25606==    by 0x503CBE3: QSettings::value(QString const&, QVariant const&) const (qsettings.cpp:3352)
==25606== 
==25606== 62,640 bytes in 290 blocks are possibly lost in loss record 11,189 of 11,199
==25606==    at 0x4025090: operator new(unsigned int) (vg_replace_malloc.c:214)
==25606==    by 0x4F61AB9: QPropertyAnimation::QPropertyAnimation(QObject*) (qpropertyanimation.cpp:148)
==25606==    by 0x9144C8E: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9151725: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9142BDE: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x9172420: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==25606==    by 0x53385D8: QWidget::event(QEvent*) (qwidget.cpp:8064)
==25606==    by 0x56F59D2: QAbstractSlider::event(QEvent*) (qabstractslider.cpp:954)
==25606==    by 0x57A767F: QSlider::event(QEvent*) (qslider.cpp:435)
==25606==    by 0x52D772B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4298)
==25606==    by 0x52DE607: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4263)
==25606== 
==25606== 66,412 bytes in 1 blocks are possibly lost in loss record 11,191 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FD51C3: QVectorData::allocate(int, int) (qvector.cpp:67)
==25606==    by 0x59C9331: QVector<QStyleOptionGraphicsItem>::realloc(int, int) (qvector.h:391)
==25606==    by 0x59BDEF0: QGraphicsViewPrivate::QGraphicsViewPrivate() (qvector.h:327)
==25606==    by 0x59BE157: QGraphicsView::QGraphicsView(QWidget*) (qgraphicsview.cpp:1048)
==25606==    by 0xAC9FFEF: ???
==25606== 
==25606== 68,288 bytes in 10 blocks are possibly lost in loss record 11,192 of 11,199
==25606==    at 0x4023C5B: calloc (vg_replace_malloc.c:418)
==25606==    by 0x4FE8C6A: _hb_alloc (harfbuzz-impl.c:41)
==25606==    by 0x4FE84CE: _HB_GPOS_Load_SubTable (harfbuzz-gpos.c:2012)
==25606==    by 0x4FEACAD: _HB_OPEN_Load_LookupList (harfbuzz-open.c:458)
==25606==    by 0x4FE8B35: HB_Load_GPOS_Table (harfbuzz-gpos.c:142)
==25606==    by 0x4FECDF9: HB_NewFace (harfbuzz-shaper.cpp:1004)
==25606==    by 0x4FF2842: qHBNewFace(void*, HB_Error (*)(void*, unsigned int, unsigned char*, unsigned int*)) (qharfbuzz.cpp:155)
==25606==    by 0x560D0F1: QFreetypeFace::getFace(QFontEngine::FaceId const&) (qfontengine_ft.cpp:242)
==25606==    by 0x560D619: QFontEngineFT::init(QFontEngine::FaceId, bool, QFontEngineFT::GlyphFormat, bool) (qfontengine_ft.cpp:667)
==25606==    by 0x56071D7: QFontEngineX11FT::QFontEngineX11FT(_FcPattern*, QFontDef const&, int) (qfontengine_x11.cpp:1107)
==25606==    by 0x5549A2C: tryPatternLoad(_FcPattern*, int, QFontDef const&, int, _FcPattern**) (qfontdatabase_x11.cpp:1664)
==25606==    by 0x554F199: loadFc(QFontPrivate const*, int, QFontDef const&) (qfontdatabase_x11.cpp:1732)
==25606== 
==25606== 78,584 bytes in 1,034 blocks are possibly lost in loss record 11,193 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x4F734AA: qMalloc(unsigned int) (qmalloc.cpp:55)
==25606==    by 0x4FD51C3: QVectorData::allocate(int, int) (qvector.cpp:67)
==25606==    by 0x4F60296: QVector<QPair<double, QVariant> >::realloc(int, int) (qvector.h:391)
==25606==    by 0x4F5F723: QVariantAnimationPrivate::setValueAt(double, QVariant const&) (qvector.h:569)
==25606==    by 0x3FECCCCB: ???
==25606== 
==25606== 110,783 bytes in 2,153 blocks are possibly lost in loss record 11,194 of 11,199
==25606==    at 0x402491C: malloc (vg_replace_malloc.c:195)
==25606==    by 0x7AE0716: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x7AE18E8: FcValueSave (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x7AE19FF: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x7AE1EF6: FcPatternAdd (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x7ADCBCD: FcFontSetList (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x7ADCE7B: FcFontList (in /usr/lib/libfontconfig.so.1.4.4)
==25606==    by 0x32A3EAD: ???
==25606== 
==25606== 544,000 bytes in 58 blocks are possibly lost in loss record 11,199 of 11,199
==25606==    at 0x4023C5B: calloc (vg_replace_malloc.c:418)
==25606==    by 0x4FE8C6A: _hb_alloc (harfbuzz-impl.c:41)
==25606==    by 0x4FE4C11: Load_PairPos (harfbuzz-gpos.c:1267)
==25606==    by 0x4FE7A88: _HB_GPOS_Load_SubTable (harfbuzz-gpos.c:5801)
==25606==    by 0x4FEACAD: _HB_OPEN_Load_LookupList (harfbuzz-open.c:458)
==25606==    by 0x4FE8B35: HB_Load_GPOS_Table (harfbuzz-gpos.c:142)
==25606==    by 0x4FECDF9: HB_NewFace (harfbuzz-shaper.cpp:1004)
==25606==    by 0x4FF2842: qHBNewFace(void*, HB_Error (*)(void*, unsigned int, unsigned char*, unsigned int*)) (qharfbuzz.cpp:155)
==25606==    by 0x560D0F1: QFreetypeFace::getFace(QFontEngine::FaceId const&) (qfontengine_ft.cpp:242)
==25606==    by 0x560D619: QFontEngineFT::init(QFontEngine::FaceId, bool, QFontEngineFT::GlyphFormat, bool) (qfontengine_ft.cpp:667)
==25606==    by 0x56071D7: QFontEngineX11FT::QFontEngineX11FT(_FcPattern*, QFontDef const&, int) (qfontengine_x11.cpp:1107)
==25606==    by 0x5549A2C: tryPatternLoad(_FcPattern*, int, QFontDef const&, int, _FcPattern**) (qfontdatabase_x11.cpp:1664)
==25606== 
==25606== LEAK SUMMARY:
==25606==    definitely lost: 1,028 bytes in 6 blocks
==25606==    indirectly lost: 3,076 bytes in 145 blocks
==25606==      possibly lost: 3,301,212 bytes in 52,165 blocks
==25606==    still reachable: 2,159,752 bytes in 33,796 blocks
==25606==         suppressed: 0 bytes in 0 blocks
==25606== Reachable blocks (those to which a pointer was found) are not shown.
==25606== To see them, rerun with: --leak-check=full --show-reachable=yes
Comment 1 Melkior 2010-11-14 14:46:14 UTC
I have problem with memory usage in kmix too - it eats up ~ 800 MB of my 2GB. I had to kill the process to be able to work normally. Running it again produces the same result.
I have kmix 4.4.3, OS: Mandriva 2010.1 with all updates.
I also remember having kmix crashed a few times.
Comment 2 Vasilis 2010-11-14 14:53:33 UTC
I second this bug. Kmix eats ~400MB of my memory. Any suggestions hoe to reduce that?
Comment 3 Vasilis 2010-11-14 14:55:29 UTC
I also think that Bug 252156 is duplicate
Comment 4 Melkior 2010-11-14 16:30:14 UTC
Seems that it's a duplicate.
In comments under that bug somebody writes, that after restart everything was ok - this is related to my situation - I haven't rebooted system for a few days now. Maybe that's why it isn't so easy to reproduce.
Anyway this shouldn't happen under any circumstances.
Comment 5 Melkior 2010-11-14 22:30:40 UTC
I've found something new - in directory "~/.kde4/share/apps/kmix/profiles" I had a file "PulseAudio.Playback_Streams.1.Controls.xml" that had ~300MB.
Inside the file there is some xml at the beginning and then a lot of "ÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃ" symbols.
Deleting the file and restarting system decreased kmix's memory usage (just restarting kmix decresaed it also, but there was no sound from any application).
The question is - why was this file so big, and why it didn't reappeared now?
Comment 6 Vasilis 2010-12-07 22:14:44 UTC
It seems that was resolved straight after the upgrade to the 4.6 beta1. Could someone re-confirm that?
Comment 8 Jens Weibler 2011-01-03 23:16:25 UTC
Same problem here (Kubuntu x64 10.04):
$ kmix -v
Qt: 4.7.0
KDE Development Platform: 4.5.1 (KDE 4.5.1)
KMix: 3.7


Normally below 50Mb RES, kmix sometimes reaches 1-2GB RES :(
Comment 9 brenddie 2011-01-04 20:30:56 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 brenddie 2011-01-04 20:32:44 UTC

$ kmix -v
Qt: 4.7.1
KDE Development Platform: 4.5.4 (KDE 4.5.4)
KMix: 3.7


always have to kill kmix after it reaches 400MB+
Comment 11 Jostein Hauge 2011-01-06 13:42:45 UTC
Same problem here. Seems like this started when kmix got pulseaudio support.

I'm using Mandriva 2010.1/2 with KDE 4.5.3 (non-official packages), but I have seen this issue since kmix got pulseaudio support.
Comment 12 Micko 2011-01-08 13:41:32 UTC
I think this should be critical due to severe memory leak. I missed this report and by mistake filed bug https://bugs.kde.org/show_bug.cgi?id=257915 It seems like the same problem.
Comment 13 Micko 2011-01-11 16:02:19 UTC
*** Bug 257915 has been marked as a duplicate of this bug. ***
Comment 14 Oliver Henshaw 2011-02-02 19:36:05 UTC
I see something similar with the java firefox plugin and a game with no
soundtrack but frequent short-lived sound effects.

This can be reproduced by loading http://www.mojang.com/notch/ld12/breaking/
(Breaking the Tower) - you don't need to play, just staying at the start screen
seems to be enough.  'smem -P kmix' reveals that memory use is constantly
growing over time.

The stream appears in the kmix playback tab, listed as "ALSA plug-in [java]:
ALSA playback", and is constantly flickering. Every so often a new copy of this
stream appears in the playback tab list; only the newest stream flickers on and
off (this may be a separate issue).

kdemultimedia-4.5.5-1.fc13.x86_64
pulseaudio-0.9.21-7.fc13.x86_64
java-1.6.0-openjdk-plugin-1.6.0.0-48.1.8.4.fc13.x86_64
Comment 15 Oliver Henshaw 2011-02-03 17:42:36 UTC
Another test is to do 'while true; do paplay /usr/share/sounds/KDE-Sys-Log-Out.ogg; done' and watch kmix USS grow with smem.

Also reproduced in KDE 4.6/Fedora 15:
pulseaudio-0.9.22-2.fc15.x86_64
kdemultimedia-4.6.0-1.fc15.x86_64
Comment 16 Jens Weibler 2011-02-06 23:56:25 UTC
Could someone please raise the severity?

This bug is not just annoying anymore but I'm really suffering. Each time my system gets slow it is because of my system swapping.

700 MiB RES memory usage is way to high.
Comment 17 Stefan Becker 2011-03-02 07:27:33 UTC
In my case I have to restart kmix every few days because of this:

$ ps -e -o pid -o rss -o size -o vsz -o comm --sort rss
...
10927 178516 437884 1270932 thunderbird-bin
11239 652292 946148 1755436 firefox
10845 673800 665916 1151696 kmix
32067 739652 1180468 1335684 qemu-kvm

Even quit doesn't seem to work anymore, it started to eat up even more memory then until I killed the process.

This is on Fedora 14/x86_64 with PulseAudio and a USB Headset as default ALSA audio sink:

$ kmix -v
Qt: 4.7.1
KDE Development Platform: 4.5.5 (KDE 4.5.5)
KMix: 3.7
Comment 18 Stefan Becker 2011-03-02 11:43:11 UTC
(addon to commet #17)
Im my case (USB headset with integrated +/- keys that generate USB HID Volume +/- events) the memory leak is likely connected to changing the volume. It is almost reproducable that after a volume change kmix memory footprint has increased.

Could this be related to the kmix volume popup window or some interaction of that window with kwin/kwin Desktop effects?
Comment 19 Oliver Henshaw 2011-03-23 00:39:42 UTC
Created attachment 58277 [details]
"valgrind --tool=massif --time-unit=ms --max-snapshots=1000 kmix" while running java game

I ran kmix in valgrind/massif while exercising the testcase in comment #14. kmix 'leaks' 200Mb or so in 30-50 minutes. Note that this probably isn't a genuine memory leak in the strictest sense, merely unbounded memory growth, see below.

Note that I also ran kmix with valgrind/memcheck with the paplay-loop testcase and, while kmix does appear to have genuine memory leaks, this probably isn't one - the summary isn't noticeably different between a do-nothing kmix session and one where the spammy paplay loop played for a few minutes. This is supported by the fact that kmix takes a lot of cpu time to tear itself down when memory use has run away.
Comment 20 Oliver Henshaw 2011-03-23 00:43:11 UTC
Created attachment 58278 [details]
"ms_print massif.out.21545 > msprint.out.2154; massdiff.py msprint.out.21545 18 645" output

I also compared two snapshots at opposite ends of the test using massdiff - http://mozakai.blogspot.com/2011/03/massdiff-diff-for-massif-snapshots.html . Hopefully this is instructive.
Comment 21 Panagiotis Papadopoulos 2011-03-25 12:42:34 UTC
I can confirm this on Arch Linux, KDE 4.6.1, x86_64.
This behaviour started after I installed and configured my system to use PulseAudio.
Comment 22 Panagiotis Papadopoulos 2011-03-25 12:47:47 UTC
Created attachment 58326 [details]
Screenshot showing KMix’ interface and its RAM usage

Also note the interface of KMix that is also displaying *old* streams, that do not exist anymore.
Comment 23 Oliver Henshaw 2011-03-25 13:35:49 UTC
(In reply to comment #22)
> Also note the interface of KMix that is also displaying *old* streams, that do
> not exist anymore.

This is probably bug #265317. Maybe it's another symptom of the underlying problem, maybe it's a separate issue.
Comment 24 Colin Guthrie 2011-03-27 14:25:44 UTC
Probably fixed in my tree. Just waiting for Christian to review.

For the eager: http://colin.guthr.ie/git/kdemultimedia-trunk/log/
Comment 25 Panagiotis Papadopoulos 2011-03-30 18:50:39 UTC
those patches seem to have have reduced the bugs impact, but the memory leaking issue is still present:

After three days of extensive (lots of changing audio sources) KMix usage the RAM usage went up to 338 MB.
This is of course *much* better than the previous 700+ MB usage, but still, I think this is not normal, is it?

:-)
Comment 26 Colin Guthrie 2011-03-30 23:50:24 UTC
Glad it's helping but yeah that does seem a bit much. Memory usage shouldn't really grow over time (a few rises and falls, but not growth per-se).

I'm guessing the problem code is:
http://colin.guthr.ie/git/kdemultimedia-trunk/tree/kmix/gui/viewbase.cpp#n226

I'm probably not clearing out everything that should be cleared out... will have to have a dig to see what I'm missing here (other people are welcome to poke about too... hint hint hint!)
Comment 27 Colin Guthrie 2011-03-31 01:04:19 UTC
OK, so having a quick look, I thought there might be a leak of _showPanelBox in ViewDockAreaPopup::add(). But in retrospect, it's actually cleared out in ViewDockAreaPopup::_setMixSet(), it's just confusing that it's got it's own variable. I've refactored this, but it's not the issue.

I looked a bit further and I think there is a leak of a KMenu every time the context menu is shown.

Fixed here: http://colin.guthr.ie/git/kdemultimedia-trunk/commit/?id=04b7595794b9e282bb24fc42a7be6a79a85af03c

I suspect it's not the only leak but it's one I happened to notice.

There could be leaks in the PA stuff specifically, but the only things I actually allocate memory for are m_mixDevices. It could be worth putting in a debug statement somewhere that prints the count of m_mixDevices every now and then and then so you can see if it's growing... If it does that would indicate where the leak could occur. I'm not sure how this could happen but looking at the code, I guess it is possible.

The only other thing that will be allocated in a general case with PA is the pa_operation*'s but I've looked and AFAICT these are all unreffed properly.

I think it would have taken a lot to generate 300Megs worth of leaked KMenus, so while it may help, I doubt this is the end of the tale...
Comment 28 Colin Guthrie 2011-03-31 01:07:20 UTC
Actually, if you did do a lot of changing of audio sources, then I guess you will have to show the context menu a lot... perhaps that is the source of the leak... fingers crossed :) Let me know in a few days (tho' I'll probably commit the fix before then anyway) :D
Comment 29 Colin Guthrie 2011-04-03 13:47:36 UTC
SVN commit 1226943 by cguthrie:

kmix: Do not allow 'channel configuration' with PulseAudio.

When the mixer is 'dynamic', configuring the channels is problematic and leads to some strange problems.
This is step one on masking that functionality when used with PA.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +6 -0      apps/kmix.cpp  
 M  +5 -0      gui/viewbase.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226943
Comment 30 Colin Guthrie 2011-04-03 13:47:38 UTC
SVN commit 1226944 by cguthrie:

kmix: Various UTF8 encoding fixes.

This ensures that data that can be UTF8 is treated as such.
Another important fix is the use of QString::number() in the stream names.

Using the number is not great in the first place but the mixer ids need
to be unique. The downside of this is that you cannot split the
channels of a stream and expect it to be restored again (it will be
restored after a reboot but only when the stream indexes match up).

Some better plan is needed here.

That said, this should help restore problems with profiles encountered
with locales that need UTF8 encoding which should also hopefully
help the memory leak that results from this.

However, profile support will still be disabled with PulseAudio backend
anyway, so it shouldn't matter much.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +28 -23    mixer_pulse.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226944
Comment 31 Colin Guthrie 2011-04-03 13:47:40 UTC
SVN commit 1226945 by cguthrie:

kmix: Avoid the use of QString.sprintf().

This is generally discouraged and also doesn't deal gracefully with UTF8
encoded data (due to explicityly calling toAscii()) so use the
more modern QString().arg(..) construct and leave the data encoding
as is. This may result in writing some UTF8 data into the config files
but this should be handled gracefully.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +3 -4      core/mixdevice.cpp  
 M  +7 -7      gui/viewbase.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226945
Comment 32 Colin Guthrie 2011-04-03 13:47:43 UTC
SVN commit 1226946 by cguthrie:

kmix: Do not save/load mixer profiles for dynamic mixers (e.g. PulseAudio)

These mixer profiles are just 'odd' when it comes to PA, especially the streams (as opposed to devices).
When used under plain ALSA mixer profiles make sense to hide the unecessary complexity
of ALSA from most users, but PA already hides that complexity and building a filter
system on top of that makes little sense and leads to strange bugs/configurations.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +22 -4     apps/kmix.cpp  
 M  +5 -1      gui/guiprofile.cpp  
 M  +13 -2     gui/viewbase.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226946
Comment 33 Colin Guthrie 2011-04-03 13:47:44 UTC
SVN commit 1226947 by cguthrie:

kmix: As we no longer allow editing of GUI Profiles for dynamic mixers, be sure to kill the 'Hide' context menu item too.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +5 -1      mdwslider.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226947
Comment 34 Colin Guthrie 2011-04-03 13:47:46 UTC
SVN commit 1226948 by cguthrie:

kmix: Kill off GUI Profile tweaks for dynamic mixers.

Now that dynamic mixers *always* use the fallback profile, we know that we don't have to
do any special fixups to display totally new devices/streams as we can be confident
the fallback GUI Profile will show them.

CCBUG: 265317
CCBUG: 237239
CCBUG: 264835

 M  +0 -36     viewbase.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226948
Comment 35 Colin Guthrie 2011-04-03 13:48:00 UTC
SVN commit 1226954 by cguthrie:

kmix: Cleanup dock area popup to clarify widget ownership/usage.

CCBUG: 237239

 M  +6 -6      viewdockareapopup.cpp  
 M  +0 -3      viewdockareapopup.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226954
Comment 36 Colin Guthrie 2011-04-03 13:48:00 UTC
SVN commit 1226955 by cguthrie:

kmix: Fix leak of the KMenu used for popup context menus

CCBUG: 237239

 M  +3 -1      viewbase.cpp  
 U             viewbase.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226955
Comment 37 Colin Guthrie 2011-04-03 13:58:00 UTC
SVN commit 1226958 by cguthrie:

kmix: Various (mostly PulseAudio related) fixes from trunk.

Merges r1225537 through r1226957.

CCBUG: 237239
CCBUG: 265317
CCBUG: 264835

 M  +37 -22    apps/kmix.cpp  
 M  +0 -1      apps/kmix.h  
 M  +2 -2      backends/mixer_backend.cpp  
 M  +57 -32    backends/mixer_pulse.cpp  
 M  +7 -9      core/mixdevice.cpp  
 M  +2 -13     core/mixdevice.h  
 M  +1 -1      core/mixer.cpp  
 M  +1 -1      core/mixer.h  
 M  +5 -1      gui/guiprofile.cpp  
 M  +11 -7     gui/mdwslider.cpp  
 M  +30 -48    gui/viewbase.cpp  
 U             gui/viewbase.h  
 M  +7 -7      gui/viewdockareapopup.cpp  
 M  +0 -3      gui/viewdockareapopup.h  
 M  +1 -1      gui/viewsliders.cpp  
 M  +0 -1      kmixui.rc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1226958
Comment 38 Panagiotis Papadopoulos 2011-04-03 14:02:14 UTC
(In reply to comment #28)
> Actually, if you did do a lot of changing of audio sources, then I guess you
> will have to show the context menu a lot... perhaps that is the source of the
> leak... fingers crossed :) Let me know in a few days (tho' I'll probably commit
> the fix before then anyway) :D

yeah, right-clicking on an audio source does increase the RAM usage of KMix by 0,1 MB everytime you show the context menu :-)
Comment 39 Colin Guthrie 2011-04-03 14:06:24 UTC
So what do you reckon Panagiotis? Think this is the fix that was needed or that there is something else still lurking in there? Feel free to close the bug if you think all is well.

As you can see from above, I've committed all these fixes to trunk and 4.6 branch now :)
Comment 40 Panagiotis Papadopoulos 2011-04-03 14:13:24 UTC
I’ll compile the latest KMix later today and report back :-)
Hopefully one of the new commits fixed it :-)

Thanks so far!
Comment 41 Oliver Henshaw 2011-04-08 18:42:19 UTC
Created attachment 58716 [details]
script to demonstrate kmix memory growth using paplay and smem

Here's a script to demonstrate the problem. I'm using smem to report memory - http://www.selenic.com/smem/ - it's in fedora, not sure whether it's in arch linux.
Comment 42 Oliver Henshaw 2011-04-08 18:50:08 UTC
Created attachment 58717 [details]
results from kmix-test.sh

And here are the results, showing how kmix memory grows with repeated paplays (and with an odd plateau at the beginning).

This is in a fairly recent F15 rawhide image, with kdemultimedia 4.6.1 + recent patches from the kdesvn 4.6 branch (everything in kdemultimedia/kmix up to r1227026 minus .desktop file changes)
Comment 43 Francesco Cepparo 2011-05-26 04:33:42 UTC
I'm also experiencing a memory leak in kmix, both with KDE 4.6.3 (kmix version 3.8) and KDE 4.7 beta 1 (kmix version 3.9-alpha), on Arch Linux with Pulseaudio.
Comment 44 Colin Guthrie 2011-05-26 10:31:30 UTC
Yeah, I've not had much time to look at KDE related stuff of late. I'll be quite KDE focused next week in Randa tho', so it should get fixed then.

It'll definitely get fixed if someone feeds me cookies while I'm doing it :p
Comment 45 Colin Guthrie 2011-06-02 14:31:45 UTC
Created attachment 60555 [details]
My results showing no change :s

I'm struggling to replicate this issue with the current git master. As you can see form my output my memory remains pretty constant.

Even on runs when this does change a bit, it still settles down after the first couple checks.

So I'm quite confused as to what could be going on here :s
Comment 46 Harald Sitter 2011-07-12 19:01:34 UTC
SVN commit 1241346 by sitter:

Do not emit signals directly but queue invokeMethod them to resolve
a memleak in KMix/Oxygen caused by PA callbacks.

Oxygen internally uses deleteLater to remove fancy animations from widgets.
Every time PA changes its sinks (for example on track change in a Phonon player),
KMix recreates its sliders thus causing animation creation inside the oxygen style.
On deletion of old sliders the oxygen additions should get deleted.
However since the switching originates in a direct call
chain from PA (via callback -> mixer impl -> emit -> kmix UI internals -> oxygen) the
deleteLater does not actually do anything and never gets executed thus leaking memory
big time (12 hours of music -> >100MB of leaked memory).
To resolve this issue the PA mixer now does not directly emit signals anymore (which
translates to a direct function call) but instead uses the mixer's QMetaObject to
deploy a *queued* invokeMethod call to the signal (therefore forcing queued emission
and execution in the QEventLoop/QThread of the target, which in our case is the
main application thread rather than the calling back PA thread).
This has the advantage that even additional connections to the mixer singals
will always get a queued emission neverminding what the type of the actual
connection is.

Also this now should resolve the only remaining memleak with PA.

CCMAIL: kde-multimedia@kde.org
CCMAIL: kde-packager@kde.org
CCMAIL: cguthrie@mandriva.org
BUG: 264089
CCBUG: 237239


 M  +18 -3     mixer_pulse.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1241346
Comment 47 Panagiotis Papadopoulos 2011-07-12 20:04:31 UTC
will this change be in the upcoming 4.7.x?
Comment 48 Harald Sitter 2011-07-13 10:33:05 UTC
Yes: http://websvn.kde.org/?view=revision&revision=1241347

Also I CC'd the KDE packagers, so depending on your distribution you might also get the fix in <=4.6.

Closing this bug as fixed.
Should you find a new memleak, please report a new bug.

best regards,
Harald
Comment 49 T.C. Hollingsworth 2011-12-10 00:39:24 UTC
This seems to have regressed in 4.7.90.  ksysguard is reporting kmix is using 144,188K at the moment.

Also reported on the Fedora KDE list:
http://article.gmane.org/gmane.linux.redhat.fedora.kde/10721
Comment 50 Rex Dieter 2011-12-10 00:43:39 UTC
please open a *new* bug, the cause is yet unknown (and likely) different.
Comment 51 T.C. Hollingsworth 2011-12-10 00:53:45 UTC
Sorry, Rex.  Filed at:
https://bugs.kde.org/show_bug.cgi?id=288619
Comment 52 Rex Dieter 2011-12-10 01:11:41 UTC
thanks!