[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Tracking allocated memory (was: Tracking memory leaks -- advice  needed)
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-06-24 6:59:21
[Download RAW message or body]

On 6/23/99, 5:48:44 PM, Harri Porten <porten@tu-harburg.de> wrote 
regarding Re: Tracking allocated memory (was: Tracking memory leaks -- 
advice  needed):
> >
> > > kpanel was the first app from KDE_1_1_BRANCH I instrumented
> > > withfprintf()'s for alloc_current. Needless to say that it leaks
> > memory
> > > constantly. The most trivial observation: on each
> > > kPanel::slotUpdateClock() the amount of allocated memory increases by
> > > 100-150 bytes _without_ any user interaction.

> After applying the following patch

> --- tools.C     1999/04/11 15:11:21     1.60.4.3
> +++ tools.C     1999/06/23 15:37:52
> @@ -647,6 +647,7 @@

>    strftime(dateline,256,i18n("\n%b %d"),loctime);

> +  QToolTip::remove(label_date);
>    QToolTip::add(label_date,
> QString(dayline)+QString(timeline)+QString(dateline));

>    if (label_date->fontMetrics().lineSpacing() * 3 <=
> label_date->height())

> I'm down to 73 bytes leakage per click. Anybody know how to get rid of
> them ? QToolTip::add() makes a deep copy but shouldn't remove() take
> care of that ?

You are right, I'm already working on that. Kpanel is full of calls to 
QToolTip::add()
without calls to QToolTip::remove(). It seems that Qt is missing a 
useful QToolTip::set().
I have already fixed all QToolTip::add() problem on my local version. 
I'll commit soon
all changes.

However, it seems that there is another memory leak in 
KPanel::setLabelDate(), in line:

   
label_date->setText(QString(dayline)+QString(timeline)+QString(dateline));

Can anyone explain why this command is leaving unfreed memory? Is it a 
Qt memory leak?

> > If other guys are interested, I can release the patch and add a short
> > section to the Harri's paper.

> Please do so. dmalloc offers so many features that it deserves an own
> paper/HOWTO though. We should then combine all materials we have on
> debugging leaks on one site.

OK.

[prev in list] [next in list] [prev in thread] [next in thread]