Hello Rene,
> > Bottom line:
> >
> > -------------------------------------------------------------------------------------------
> > ROOT doesn't allow to assigned any value to the class pointers but zeros
> > with the class default ctor.
> > -----------------------------------------------------------------------------------
>
> No problems. see ROOT Users Guide page 194
>
Thank you very much for this
However I am still wondering if one could avoid this problem and how ?
The class was written a while ago, and it was not changed, and it has been working quite well.
So there was no reason to revise its source.
Then I was very lucky because my program crashed. Let's imagine this pointer would point
to the heap object rather to the stack one.
In this scenario I may not have any crash at all but the behavior on the entire program might
have been changed slightly.
The worse thing here is the entire code changes its behavior but the object that causes
the troubles is perfect !
> In case you create objects in the default constructor (your case
> in TVolumePosition with the member fMatrix), you can instruct ROOT I/O of this
> situation by specifying "->" as the first characters of the comment field.
> In this case:
> - I/O will be faster; fMatrix->Streamer(buf) will be called instead of
> buf << fMatrix;
> - the file will be slightly smaller (no need to save the class identifier
> at each write.
> - the member will not be deleted when reading (just overwritten).
This is even worse, since it doesn't delete the Identity matrix but simply fills it
with non identity values.
> Note that in case you wrote a file with the old fMatrix declaration,
> you can read it by instruction ROOT to NOT delete the object when reading with:
> TStreamerInfo::SetCanDelete(kFALSE);
Ooo this is a solution. Why this is not default ?
>
> For example, I can read your file starGeom.root with:
> TStreamerInfo::SetCanDelete(kFALSE);
> gSystem->Load("libStar");
> TFile f("starGeom.root");
> TVolume *hall = (TVolume*)f.Get("HALL");
>
> If now, you write again the TVolume object into a new file, eg
> TFile f2("newstarGeom.root","recreate");
> hall->Write();
>
> in the following session, you can do directly:
> gSystem->Load("libStar");
> TFile f("newstarGeom.root");
> TVolume *hall = (TVolume*)f.Get("HALL");
>
Thank you. I have to think now.
My question was:
> > Now the question is it "by design" and my class should be redesigned or
> > the problem could be fixed ?
What you say means what I got is "be design" and I have to change my class now.
Honestly I've found one has to change it anyway. Just I got a good reason to do that.
My best regards, Valeri
> Rene Brun
>
> --------
> >
> > I've found a reason for one of the crash reported today.
> > This is due a new ROOT I/O schema imposes some new constrain.
> >
> > In this particular case the ctor of TVolumePosition class
> > http://root.cern.ch/root/htmldoc/src/TVolumePosition.cxx.html#TVolumePosition:TVolumePosition
> > contains a statement:
> >
> > if (!fMatrix) fMatrix = TVolume::GetIdentity();
> >
> > This is to assign a pointer to the static Identity matrix in case it is not provided by
> > the user code.i.e it is a default value !!! and this value is NOT zero.
> >
> > What happens when the object is read by the new ROOT i/o layer.
> >
> > 1. It instantiates TVolumePosition calling its default ctor.
> > As result fMatrix is assigned to the static object pointer "by default".
> >
> > 2. ROOT does apply a "delete" statement to all pointers of the new created object.
> > "Usually" all pointers are still zero and cause no big problem.
> >
> > 3. In this case the pointer fMatrix points to the static stack object. It is
> > NOT zero and "delete" causes the program crash.
> >
> > So the bottom line:
> >
> > -------------------------------------------------------------------------------------------
> > Default ctor is not allowed to assigned any value to the class pointer but zeros.
> > -------------------------------------------------------------------------------------------
> >
> > Now the question is it "by design" and my class should be redesigned or
> > the problem could be fixed ?
> >
> > What about Bill Love's TTree troubles I suspect his class has "not right" ctor as well.
> > I'll check this tomorrow.
> >
> > With my best regards, Valeri
> >
> > -----
> > Dr.Valeri Fine
> > STAR/US Atlas E-mail: fine@bnl.gov
> > Brookhaven National Lab Phone: +1 631 344 7806
> > Upton, NY 11973-5000 FAX: +1 631 344 4206
> > USA
> >
> > ----- Original Message -----
> > From: "Rene Brun" <brun@pcbrun.cern.ch>
> > To: "Valeri Fine" <fine@bnl.gov>
> > Cc: <roottalk@pcroot.cern.ch>
> > Sent: Monday, December 10, 2001 5:03 PM
> > Subject: Re: [ROOT] Re: ROOT] LAST CALL for comments before closing ROOT version 3.02
> >
> > > Hi
> > >
> > > On Mon, 10 Dec 2001, Valeri Fine wrote:
> > >
> > > > Hello Rene,
> > > >
> > > > > We intend to release Root version 3.02/06 this week. This will be the PRO
> > > > > release.
> > > >
> > > > He have discovered several problems with the last version of ROOT from CVS
> > > >
> > > > 1. We can not read back our files written half year ago (with ROOT 3.00.06)
> > > > We have not had any problem to read them with ROOT versions 3.02.00 / 01
> > >
> > > Could you be more explicit? I cannot do anything with just this info.
> > >
> > > >
> > > 2. We
> > > can not use TChain to read several TTrees' in row (See Bill Love's report)
> > > > The macro crashes occasionally
> > >
> > > I am waiting from Bill a session where he can reproduce the problem.
> > >
> > > >
> > > 3. We can not read the new files with TVolume objects,
> > > > but we can read the old versions of there files though.
> > >
> > > TVolume has not been modified in version 3.02.
> > >
> > > >
> > > > We are working to understand the reasons of these new problems and will appreciate you
> > > > will wait a little with your release.
> > >
> > > Why are you reporting these problems only now?
> > > >
> > > > Have you any idea what has happened with ROOT i/o recently, that may have affected the
> > > > backward compatibility ?
> > >
> > > So far, you are the only one complaining. If there are other people with
> > > the same experience, please let me know.
> > >
> > > When you encounter an I/O problem, I suggest the following procedure:
> > > Set gDebug=2; before reading or writing. The I/O functions in
> > > TStreamerInfo
> > > will print one line for each data member of a class being read/written.
> > > It also shows the persistent class definition. This should help you
> > > to localize the problem.
> > >
> > > Rene Brun
> > >
> > >
> > > >
> > > > With my regards, Valeri
> > > > -----
> > > > Dr.Valeri Fine
> > > > STAR/US Atlas E-mail: fine@bnl.gov
> > > > Brookhaven National Lab Phone: +1 631 344 7806
> > > > Upton, NY 11973-5000 FAX: +1 631 344 4206
> > > > USA
> > > >
> > > >
> > > >
> > > >
> > >
>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:11 MET