Hello,
I have a question about the root IO: does the TTree supposed to read/write
the object which is derived from fully abstract class?
Here are details of my problem:
I need to write/read using the TTree the TClonesArray of the
object. One of the ancestor classes of this object is fully abstract.
(provides some general data members/methods for derived classes)
class NaTrack :
public NaRecParticle {
// ..
virtual NaCluster1D* GetCluster(Int_t i) const=0; // !!!
//this method is abstract, depends on derived track version
protected:
Int_t fNClusters; // Number of contributing clusters
Int_t fClusters[kMaxClusters]; // Clusters Id's (in the station)
//
ClassDef(NaTrack,1) // NA60 Reconstructed Base Track Class
};
Surely, the derived class (NaPCMuon) which goes into the TClonesArray implements its
virtual NaCluster1D* GetCluster(Int_t i).
class NaPCMuon :
public NaTrack
{
//....
virtual NaCluster1D* GetCluster(Int_t i) const;
//..
};
The following happens at IO stage:
1) When I write the tree, close it and read it back in the same root
session, everything works well.
2) But if I quit and start new root
session, I get seg.vol. reading the branch containing mentioned TClonesArray.
Running with the .T and gDebug=1 gives:
1) in the same root session:
...
ReadBufferClones, class:NaPCMuon, name=NaTrack, fType[0]=0, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaTrack, name=NaRecParticle, fType[0]=0, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaRecParticle, name=TObject, fType[0]=66, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaRecParticle, name=fPXYZ, fType[1]=25, offset=12, TStreamerBasicType, bufpos=152, nc=2
....
// !!!! This part corresponds to fully abstract ancestor:
ReadBufferClones, class:NaTrack, name=fNClusters, fType[1]=3, offset=64, TStreamerBasicType, bufpos=250, nc=2
ReadBufferClones, class:NaTrack, name=fClusters, fType[2]=23, offset=68, TStreamerBasicType, bufpos=258, nc=2
// !!!!
...
ReadBufferClones, class:NaPCMuon, name=fParsUncorr, fType[1]=25, offset=168, TStreamerBasicType, bufpos=450, nc=2
Works fine!
2) If I read the tree in the new root session, it first rebuilds the TStreamerInfo:
====>Rebuilding TStreamerInfo for class: NaPCMuon, version: 1
====>Rebuilding TStreamerInfo for class: NaTrack, version: 1
====>Rebuilding TStreamerInfo for class: NaRecParticle, version: 1
StreamerInfo for class: NaRecParticle, version=1
BASE TObject offset= 0 type=66 Basic ROOT object
Float_t fPXYZ[3] offset= 12 type=25 Px,Py,Pz of the Particle
Float_t fVXYZ[3] offset= 24 type=25 x,y,z of the Particle beginning
Float_t fMass offset= 36 type= 5 Imposed mass
Float_t fPt offset= 40 type= 5 Particle Pt
Float_t fYLab offset= 44 type= 5 Lab Rapidity
Char_t fCharge offset= 48 type= 1 Particle charge
Float_t fChi2 offset= 52 type= 5 Particle quality
Int_t fNumber offset= 56 type= 3 Index in the Particles list
Int_t fVertexId offset= 60 type= 3 Id of the vertex to which it is attached
i= 0, TObject type= 66, offset= 0, len=1, method=0
i= 1, fPXYZ type= 25, offset= 12, len=3, method=0
i= 2, fVXYZ type= 25, offset= 24, len=3, method=0
i= 3, fMass type= 5, offset= 36, len=1, method=0
i= 4, fPt type= 5, offset= 40, len=1, method=0
i= 5, fYLab type= 5, offset= 44, len=1, method=0
i= 6, fCharge type= 1, offset= 48, len=1, method=0
i= 7, fChi2 type= 5, offset= 52, len=1, method=0
i= 8, fNumber type= 3, offset= 56, len=1, method=0
i= 9, fVertexId type= 3, offset= 60, len=1, method=0
StreamerInfo for class: NaTrack, version=1
BASE NaRecParticle offset= 0 type= 0 NA60 Reconstructed Particle Class
Int_t fNClusters offset=99999 type= 3 Number of contributing clusters !!!! Wrong offsets
Int_t fClusters[24] offset=99999 type=23 Clusters Id's (in the station)
i= 0, NaRecParticle type= 0, offset= 0, len=1, method=157383136
i= 1, fNClusters type= 3, offset=99999, len=1, method=0
i= 2, fClusters type= 23, offset=99999, len=24, method=0
StreamerInfo for class: NaPCMuon, version=1
BASE NaTrack offset= 0 type= 0 NA60 Track Class
Float_t fParsUncorr[6] offset=168 type=25 ax,ay,bx,by,pfit,pcomp of Forward Space Track
Int_t fSextantId offset=200 type= 3 Sextant ID
Float_t fSlopErr2 offset=204 type= 5 RRR
i= 0, NaTrack type= 0, offset= 0, len=1, method=157415504
i= 1, fParsUncorr type= 25, offset=168, len=6, method=0
i= 2, fSextantId type= 3, offset=200, len=1, method=0
i= 3, fSlopErr2 type= 5, offset=204, len=1, method=0
ReadBufferClones, class:NaPCMuon, name=NaTrack, fType[0]=0, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaTrack, name=NaRecParticle, fType[0]=0, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaRecParticle, name=TObject, fType[0]=66, offset=0, TStreamerBase, bufpos=132, nc=2
ReadBufferClones, class:NaRecParticle, name=fPXYZ, fType[1]=25, offset=12, TStreamerBasicType, bufpos=152, nc=2
ReadBufferClones, class:NaRecParticle, name=fVXYZ, fType[2]=25, offset=24, TStreamerBasicType, bufpos=176, nc=2
ReadBufferClones, class:NaRecParticle, name=fMass, fType[3]=5, offset=36, TStreamerBasicType, bufpos=200, nc=2
ReadBufferClones, class:NaRecParticle, name=fPt, fType[4]=5, offset=40, TStreamerBasicType, bufpos=208, nc=2
ReadBufferClones, class:NaRecParticle, name=fYLab, fType[5]=5, offset=44, TStreamerBasicType, bufpos=216, nc=2
ReadBufferClones, class:NaRecParticle, name=fCharge, fType[6]=1, offset=48, TStreamerBasicType, bufpos=224, nc=2
ReadBufferClones, class:NaRecParticle, name=fChi2, fType[7]=5, offset=52, TStreamerBasicType, bufpos=226, nc=2
ReadBufferClones, class:NaRecParticle, name=fNumber, fType[8]=3, offset=56, TStreamerBasicType, bufpos=234, nc=2
ReadBufferClones, class:NaRecParticle, name=fVertexId, fType[9]=3, offset=60, TStreamerBasicType, bufpos=242, nc=2
ReadBufferClones, class:NaTrack, name=fNClusters, fType[1]=3, offset=99999, TStreamerBasicType, bufpos=250, nc=2
*** Break *** segmentation violation
Root > Function readrec() busy flag cleared
As one can see, all data members of the abstract class have offset = kMissing !
The fact that it happens on when TStreamerInfo::BuildOld() methos is used makes
me to think that this is a bug. Is that so?
Best regards,
Ruben
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:52 MET