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
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.
I second this bug. Kmix eats ~400MB of my memory. Any suggestions hoe to reduce that?
I also think that Bug 252156 is duplicate
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.
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?
It seems that was resolved straight after the upgrade to the 4.6 beta1. Could someone re-confirm that?
https://bugzilla.redhat.com/show_bug.cgi?id=612331
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 :(
*** This bug has been confirmed by popular vote. ***
$ 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+
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.
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.
*** Bug 257915 has been marked as a duplicate of this bug. ***
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
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
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.
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
(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?
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.
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.
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.
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.
(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.
Probably fixed in my tree. Just waiting for Christian to review. For the eager: http://colin.guthr.ie/git/kdemultimedia-trunk/log/
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? :-)
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!)
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...
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
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
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
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
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
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
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
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
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
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
(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 :-)
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 :)
I’ll compile the latest KMix later today and report back :-) Hopefully one of the new commits fixed it :-) Thanks so far!
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.
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)
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.
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
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
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
will this change be in the upcoming 4.7.x?
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
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
please open a *new* bug, the cause is yet unknown (and likely) different.
Sorry, Rex. Filed at: https://bugs.kde.org/show_bug.cgi?id=288619
thanks!