Peter,
Would the suggestion you make do any more than is already done using the ROOT
object collection statistics? For example, if you do gObjectTable->Print(),
you will get a list of all root objects created if object collection
statistics is turned on. In case anyone doesn't know, this is done in the
.rootrc file using Root.ObjectStat: 1
Regards
Kris
"Peter H. L. Christiansen" wrote:
> Hi trackers and devs
>
> SUGGESTION :
> It is possible to make static counting variables in the data classes and
> maybe even for the BrDataTable since at least I often have a way of
> clearing before deleting and then build up a huge pile of these.
> A memory class could then be made that you can call and ask what is the
> status of all these static variables, i.e., how many objects have been
> created but not deleted.
>
> Does anybody think this is a good idea ?
> The static counters is at least how I identified 2 of the following 3
> leaks.
>
> I found 3 memory leaks in the clustering algorithm.
> Maybe they are corrected in the new version of brat, but I did not want to
> mess up my own (7 days old), so sorry if that is the case.
>
> **
> BrTPCClusterFinder :
> When nPeaks == 1 and deconvoluting a BrTPCCluster object is created but
> not destroyed. This adds up, but if it is all of the memory leak in the
> tracking algorthm I don't know, but I am looking at it.
>
> To correct this you could do
> if ( nPeaks > 1 ) {
> .......bla bla bla
> } else if ( cluster->GetStatus() == BrTPCCluster::kMultiHit &&
> nPeaks == 1 ) {
> BrTPCCluster *currCluster = cluster;
> BrTPCCluster *oneCluster = (BrTPCCluster *)subClusters.At( 0 );
> fClusterTable->AddCluster( currCluster, oneCluster );
> currCluster = oneCluster;
> fClusterTable->RemoveCluster( cluster, lnk );
> }
>
> Do we want to something special with this cluster ? Is it really a super
> cluster ?
> Here at NBI we have been discussing a little bit the deconvolution and JJ
> pointed out that this could of course be done differently if there is a
> characteristic cluster width. A bit like what you talked about Trine.
>
> Also in destructor :
> if( fClusterTable ) {
> fClusterTable->Clear();
> delete fClusterTable;
> fClusterTable = 0;
> }
> is needed
>
> **
> Second memory leak is in
> BrTPCClusterFinder::FillSubClusters
> after
> cluster->AddSeq( *seq );
> we need
> delete seq;
> or AddSeq should just take the adress - propably the best solution.
>
> **
> 3rd memory leak
> add
> delete [] amp;
> in
> Bool_t BrTPCHitClusterFinder::FindHits ( method 1 )
>
> In
> Bool_t BrTPCHitClusterFinder::FindHits2 ( method 2 )
> delete [] tcharge;
> delete [] dtcharge;
> delete [] ytime;
>
> delete [] pcharge;
> delete [] dpcharge;
> delete [] xpad;
> is missing
>
> Unfortunately it seems that there is also a leak in the tracking algorithm
> and I will try to find it tomorrow.
>
> I will correct the above mentioned leaks when I find the tracking leaks
> and can get rid of my very useful, but also very fubar BRAT version.
>
> Waiting for comments,
> Peter
>
> :-) --------------------------------- )-:
> |Peter H L Christiansen aka PAN @ NBI |
> |EMAIL : pchristi@nbi.dk |
> |OFFICE : Tb1 @ NBI |
> |PHONE : 353 25269 <- New!! |
> |SNAIL : Sdr. Fasanvej 14 ST 2000 F |
> |PHONE : 38 872042 |
> :-D --------------------------------- \-:
This archive was generated by hypermail 2b29 : Tue Jun 13 2000 - 15:37:24 EDT