Re: [ROOT] fatal in operator delete

From: Rene Brun (Rene.Brun@cern.ch)
Date: Fri Mar 30 2001 - 22:18:24 MEST


Hi Michael,
Your original TH1F dull object is not in the f directory.
To check this, just add f.ls() after the creation of the file.
Your problem seems to be that in the call mc.SetHist(dull) 
you make a copy !!!!! of the original object.
I cannot tell you more without looking at your class.

Concerning your other points. It is bad practice to allocate 
histograms in the stack if they are associated with a file.
When closing the file, this object will be deleted.

I strongly suggest you always use named macros and follow
the C++ rules, scoping, etc, as much as possible.

Unnamed macros create objects in the global scope. You must
be careful, in this case, when you reexecute the macro.

Rene Brun

On Fri, 30 Mar 2001, Michael Kordosky wrote:

> 
> I am having a little problem with the following macro:
> 
> {
> gROOT->Reset();
> 
> gSystem->Load("libMyClasses.so");
> 
> TH1F dull("dull","dullhisto",100, -5, 5);
> for(Int_t i=0; i<1000; i++){
> 	dull.Fill( (gRandom->Gaus(1.5, .5)) );
> }
> cout<<"dull.GetMean(): "<<dull.GetMean()<<endl;
> 
> 
> TFile f("test.root", "RECREATE");
> 
> MyClass mc;
> mc.SetType("tester");
> mc.SetTube(2);
> mc.SetPixel(5);
> 
> mc.SetHist(dull);
> cout<<"mc.GetMean(): "<<mc.GetMean()<<endl;
> f.ls();
> mc.Write();
> f.ls();
> f.Close();
> }
> 
> The macro outputs:
> 
> root [0] .x test.C
> dull.GetMean(): 1.47894
> mc.GetMean(): 1.47894
> TFile**		test.root
>  TFile*		test.root
>   OBJ: TH1F	dull	dullhisto : 0
> TFile**		test.root
>  TFile*		test.root
>   OBJ: TH1F	dull	dullhisto : 0
>   KEY: MyClass	MyClass;1
> root [1] f.Close();
> Fatal in <operator delete>: storage area overwritten
> aborting
> *ROOT crashes out at this point*
> 
> This result suprised me in two ways:
> (1) Why is the TH1F "dull" added to the test.root directory?  I would not
> have expected this behaviour, considering that dull was created prior to
> opening the TFile.
> (2) I suspect the crash is due to (1).  When the file closes, it writes
> out dull, which invalidates it.
> {See for reference the User's Guide p168. They use heap objects and
> pointers there though.}
> 
> Also:
> If I open a browser and access the TFile, A MyClass object is indeed in
> there.  This is what I expected.  If I double click the MyClass object, it
> pulls up the Object Inspector (ok).  It also then shows a TH1F within the
> right browser window (ok, wasn't sure what would happen).  Further double
> clicks on the MyClass object produce more histograms though!  Why is this.
> It is perhaps not disaster, but rather confusing to look at!  They seem to
> be clones of each other (rather than references to one object), since if I
> smooth one of them, the others do not reflect the change when drawn.  How
> can I understand/get rid of  this behaviour?
> 
> Some time ago a collegue told me that she always wrote compiled code
> because macros often did unexpected things.  I tend to find myself in the
> same boat.  As an observation, I notice that tutorials and the users
> manual examples tend to feature much more dynamic allocation than I would
> normally write.  I don't really appreciate why this is, perhaps
> it's only stylistic, but maybe I need to change my coding practices when
> writing macros?
> 
> Comments greatly appreciated!
> 
> Mike Kordosky
> 
> -- 
> Graduate Research Assistant  // High Energy Physics Lab
> kordosky@hep.utexas.edu     // University of Texas at Austin
> ph: (512) 471-8426 (RLM Lab, Office)
>     (512) 475-8673 (ENS Lab)
> 



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:40 MET