RE: [ROOT] problem with stl functions

From: Philippe Canal (pcanal@fnal.gov)
Date: Fri Jun 27 2003 - 17:45:02 MEST


Hi Pierre,

In the copy constructor you sent me, the data member Pmt can be unitialized (thus leading to unspecified behavior).  However, I would need to see the assignement operator (IoSdStation::operator=).

> The files that we have already produced with this new data format are divided by two in size.  

Did you considers using 2 trees and/or replacing the pointer to the IoSdFadc by a TRef?

Cheers,
Philippe


-----Original Message-----
From: Pierre Da Silva [mailto:Pierre.DaSilva@lpnhep.in2p3.fr]
Sent: Friday, June 27, 2003 10:35 AM
To: Philippe Canal
Cc: roottalk@pcroot.cern.ch
Subject: RE: [ROOT] problem with stl functions


	Hi Philippe,

On Fri, 27 Jun 2003, Philippe Canal wrote:

> Hi Pierre,
> 
> There is nothing obviously wrong in the code.  With the latest ROOT the
> proper sequences of constructor and destructor seems to be called for your
> IoSdStation.  So my only guess would be to look carefully at the
> implementation of the assignement operator for that class (which you did not
> send).
here it is :

	IoSdStation::IoSdStation (const IoSdStation & st)
	{
	  Gps = NULL; Histo= NULL; Calib = NULL; Fadc=NULL; //Pmt=NULL;
	  Error = st.Error;Id = st.Id; Name = st.Name;
	  Easting = st.Easting; Northing = st.Northing; Altitude = st.Altitude;
	  Trigger = st.Trigger;
	  if (st.Gps) {Gps = new IoSdGps; memcpy(Gps, st.Gps, 
	sizeof(IoSdGps&));}
	  if (st.Histo) {Histo = new IoSdHisto; memcpy(Histo, st.Histo, 
	sizeof(IoSdHisto&));}
	  if (st.Calib) {Calib = new IoSdCalib; memcpy(Calib, st.Calib, 
	sizeof(IoSdCalib&));}
	  if (st.Fadc) {Fadc = new IoSdFadc; memcpy(Fadc, 
	st.Fadc,sizeof(IoSdFadc&));}
	  if (st.Pmt) {Pmt = new IoSdPmt; memcpy(Pmt, st.Pmt,sizeof(IoSdPmt&));}
	}


 
> Even if there was a memory leak, the fact that you accumulate memory until
> it crashes leads me to believe that you have a very large number of
> IoSdEvent object.  Is there a reason you chose not to use a TTree for this
> purpose?  It seems like it would be much more efficient.

Yes, there is several reasons, the main one is that we do not want to have 
as many entries for the "Fadc" objects as for the "IoSdStation" object. We 
are going to work with a lot "IoSdStation" objects (1600), and we don't 
want to have Gigabytes files. The files that we have already produced with 
this new data format are divided by two in size.  

					Pierre


> 
> Cheers,
> Philippe.
> 
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
> [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Pierre Da Silva
> Sent: Friday, June 27, 2003 9:06 AM
> To: roottalk@pcroot.cern.ch
> Subject: [ROOT] problem with stl functions
> 
> 
> 	Dear rooters,
> 
> 	We have a TFile filled with "IoSdEvent" objects. When we take one
> object out (see the piece of code below), memory is growing up until
> everything crashes. We know that this came from one vector of
> "IoSdStation" objects, but we don't know how and why. Notice that this
> problem only appears when reading the objects, and not when writing them
> on the file.
> 
>   TFile f3("converted.root","READ");
>   TList *list = f3.GetListOfKeys();
>   TIter next(list);
>   TKey *tmpkey;
>   IoSdEvent mem;
>   while((tmpkey = (TKey *)next())) {
>     tmpkey->Read((TObject *)&mem);
>     cout<<" "<<mem.Id<<endl;
>   }
> 
> I join our classes in the attached file. Thanks in advance.
> 
> 
> 				###############################
> 				Pierre Da Silva
> 				Email: pdasilva@lpnhep.in2p3.fr
> 				Tel.: 01 44 27 62 74
> 
> 				LPNHE
> 				4, place Jussieu
> 				Tour 33 - Rez de Chaussee
> 				75252 PARIS Cedex 05 - FRANCE
> 				Tel.: 01 44 27 63 13
> 			 	Fax: 01 44 27 46 38
> 				###############################
> 
> 
> #################################################################
> #################################################################
> #################################################################
> #####
> #####
> #####
> #################################################################
> #################################################################
> #################################################################
> 



This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:12 MET