Summary: | Plasma crash (QGraphicsItemPrivate::updateCachedClipPathFromSetPosHelper, QGraphicsItemPrivate::setPosHelper) | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Travis McHenry <wordsizzle> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andresbajotierra, aseigo, darktears31, deblauwetom, kde, sputnikshock, user581 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Travis McHenry
2009-07-07 02:50:06 UTC
the backtrace never leaves QGrapicsView code, so this is likely an upstream problem. for the other issue: * what widgets are you running? * what wallpaper style do you use? (e.g. slideshow?) * does it still leak with 4.3rc1? So it's Qt's fault? should I send this crash report on over to their bug tracker? Yes, it does leak with 4.3rc1 Wallpaper Type: Basic image. Widgets I use: Folder View 3xClock widgets (used to be 1 and no change when adding 2 so I doubt they're at fault) Sticky note openDesktop LCD Weather Station CPU Monitor Pastebin Microblog ScreenSaverSwitch (slightly modified from http://www.kde-look.org/content/show.php/Screen+Saver+Switch?content=93752 ) but there's not much to leak there. Then the standard panel stuff, application menu, pager, kate session applet, recent devices, systray, task manager, network manager, trash can. I'm around 90% sure microblog does leak memory, i've used it inside plasmoidviewer and watched the memory grow as dents/tweets come in. Using a very meagre understanding of the microblog code maybe this excerpt is at fault?: //add the newbies int newCount = 0; uint maxId = m_lastTweet; foreach (const QString &id, data.keys()) { uint i = id.toUInt(); if (i > m_lastTweet) { newCount++; QVariant v = data.value(id); //Warning: This function is not available with MSVC 6 Plasma::DataEngine::Data t = v.value<Plasma::DataEngine::Data>(); m_tweetMap[i] = t; if (i > maxId) { maxId = i; } } } m_lastTweet = maxId; m_newTweets = qMin(newCount, m_historySize); m_flash->flash( i18np( "1 new tweet", "%1 new tweets", m_newTweets ), 20*1000 ); showTweets(); /////// It's kinda hard for me to follow but it appears to just keep increasing the size of m_tweetMap. Seems a waste to let it increase past the m_historySize at all since it's refreshed on saveSettings. This might be completely misinformed, but this seems like the thing to do: while(m_tweetMap.size() >= m_historySize) m_tweetMap.remove(m_tweetMap.keys().first()); m_tweetMap[i] = t Seems off, but you get the idea. It's also important to note that I'm probably an extreme use case here, I leave my computer on pretty much 24/7 restarting only for kernel and other major updates (such as kde4.3rc1) So it took 4 days for memory to get to ~350mb/~350mb(swap) from ~50mb. Thanks for your time. :) Travis. SVN commit 992497 by aseigo: don't continue to add to the tweet map. not technically a memory _leak_, but certainly a memory growth. *sigh* this widget has had a very spotty time with memory management. thanks to Travis McHenry for doing the investigation CCBUG:199226 M +8 -4 microblog.cpp M +3 -3 microblog.h WebSVN link: http://websvn.kde.org/?view=rev&revision=992497 *** Bug 197067 has been marked as a duplicate of this bug. *** *** Bug 200563 has been marked as a duplicate of this bug. *** *** Bug 200770 has been marked as a duplicate of this bug. *** Bug 200770 is another report related to the openSocial widget. *** Bug 199896 has been marked as a duplicate of this bug. *** |