plasma memory/pixmap leak ?

Asraniel asraniel at fryx.ch
Thu Jun 24 08:07:50 CEST 2010


that one is fixed in trunk, it was caused by a change in the dataengines.

Beat Wolf

Am Donnerstag 24 Juni 2010, um 08.05:48 schrieb Kåre Särs:
> On Thursday 03 June 2010 00:19:02 Zack Rusin wrote:
> > On Wednesday 02 June 2010 14:40:28 R.F. Pels wrote:
> > > >> So, basically, the short answer is 'No'.
> > > > 
> > > > there is no instrumentation system, no. much like most other plugin
> > > > based software out there. if you'd like to develop something, that'd
> > > > be great.
> > > 
> > > Huh. Methinks that would require at least SOME community effort. Ehm,
> > > ISTM that this isn't something one can invent and develop on its own.
> > > Pointers? Where to start?
> > 
> > I'd just link Plasma with Google heap profiler, it's part of the google
> > perf tools package:
> > http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html
> > We've been using it for profiling drivers with pretty decent results.
> > They work a lot better if one is trying to get a global view of the
> > system and not just a very limited app wise scope that *algrind tools
> > present. The best strategy in this case would be creating a base profile
> > and then just diffing it against a long running sessions.
> > Also google perf tools are pretty fast so for a while I'd probably leave
> > them on in all debug builds so that if anyone running svn sees their
> > Plasma misbehaving then can just immediately send over the trace to the
> > list.
> 
> I'm also experiencing a memory leak in beta2, but I have narrowed it down
> to the Systemloadviewer. The only problem is that I can not see a any
> commits in the history log of the applet that could result in this memory
> leak compared to KDE SC 4.4....



More information about the Plasma-devel mailing list