Problem with Reading Root File

ayben · March 29, 2011, 12:04pm

Dear Experts,

I’m trying to plot histograms from a small root file with using following way,

TFile *TPCTOFEfffile = TFile::Open("EFFTPCTOF.root","read");


TH1F* TPCTOFEFFDeltapp = (TH1F*)(TPCTOFEfffile->FindObject(hEff;1)) ;
TH1F* TPCTOFEFFDeltamm = (TH1F*)(TPCTOFEfffile->FindObject(hEff;2)) ;
TH1F* TPCTOFEFFAverage = (TH1F*)(TPCTOFEfffile->FindObject(hEff;3)) ;

TCanvas *d23 = new TCanvas("d23","efficiency*acc",0,0,950,700); 

TPCTOFEFFDeltapp->Draw();
TPCTOFEFFDeltamm->Draw("same");
TPCTOFEFFAverage->Draw("same");
d23->SaveAs("TPC_TOF_EFF_ACC.eps");

This gives following crash,

root [0] .x test.C

 *** Break *** segmentation violation



===========================================================
There was a crash (#7 0x002f6b6d in SigHandler ()).
This is the entire stack trace of all threads:
===========================================================
#0  0x00110402 in __kernel_vsyscall ()
#1  0x02ad6953 in __waitpid_nocancel () from /lib/libc.so.6
#2  0x02a7abab in do_system () from /lib/libc.so.6
#3  0x052038dd in system () from /lib/libpthread.so.0
#4  0x002f279d in TUnixSystem::Exec ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#5  0x002f9c0d in TUnixSystem::StackTrace ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#6  0x002f6a98 in TUnixSystem::DispatchSignals ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#7  0x002f6b6d in SigHandler ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#8  0x002f0014 in sighandler ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#9  <signal handler called>
#10 0x004245f4 in G__G__Base2_10_0_15 ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#11 0x009c1a8a in Cint::G__ExceptionWrapper ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#12 0x00a7c076 in G__execute_call ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#13 0x00a8063d in G__call_cppfunc ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#14 0x00a533e3 in G__interpret_func ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#15 0x00a41088 in G__getfunction ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#16 0x00b3feec in G__getstructmem ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#17 0x00b35bc8 in G__getvariable ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#18 0x00a148f1 in G__getitem ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#19 0x00a1f3b5 in G__getexpr ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#20 0x00ab2ab0 in G__exec_statement ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#21 0x00a555f6 in G__interpret_func ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#22 0x00a411fd in G__getfunction ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#23 0x00a149e1 in G__getitem ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#24 0x00a1f3b5 in G__getexpr ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#25 0x00a25fcd in G__calc_internal ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#26 0x00abea87 in G__process_cmd ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCint.so
#27 0x002b0ac3 in TCint::ProcessLine ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#28 0x002b06df in TCint::ProcessLineSynch ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#29 0x00203989 in TApplication::ExecuteFile ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#30 0x00203f1c in TApplication::ProcessFile ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#31 0x00200a95 in TApplication::ProcessLine ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#32 0x0082d234 in TRint::HandleTermInput ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libRint.so
#33 0x0082b575 in TTermInputHandler::Notify ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libRint.so
#34 0x0082dd04 in TTermInputHandler::ReadNotify ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libRint.so
#35 0x002f667b in TUnixSystem::CheckDescriptors ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#36 0x002f7202 in TUnixSystem::DispatchOneEvent ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#37 0x00263be1 in TSystem::InnerLoop ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#38 0x00267d01 in TSystem::Run ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#39 0x001ff1a8 in TApplication::Run ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libCore.so
#40 0x0082d7ff in TRint::Run ()
   from /home/myroot/CERN2/alice/packages/VO_ALICE/ROOT/v5-28-00a/v5-28-00a/lib/libRint.so
#41 0x08048d83 in main ()
===========================================================

The crash is most likely caused by a problem in your script.
Try to compile it (.L myscript.C+g) and fix any errors.
If that does not help then please submit a bug report at
[root.cern.ch/bugs](http://root.cern.ch/bugs). Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.


Root > Function test() busy flag cleared

Please help me to find where I’m doing wrong.

Thank you,

Kind regards,

Ayben
test.C (478 Bytes)
EFFTPCTOF.root (4.84 KB)

Pepe_Le_Pew · March 29, 2011, 1:43pm

An expert’s advice is needed, why there is a “segmentation violation” in the code below.

{
  TFile *TPCTOFEfffile = TFile::Open("EFFTPCTOF.root", "read");
  
#if 1 /* 0 or 1 */
  // This method works well.
  TH1F *TPCTOFEFFDeltapp = (TH1F*)(TPCTOFEfffile->FindObjectAny("hEff;1"));
  TH1F *TPCTOFEFFDeltamm = (TH1F*)(TPCTOFEfffile->FindObjectAny("hEff;2"));
  TH1F *TPCTOFEFFAverage = (TH1F*)(TPCTOFEfffile->FindObjectAny("hEff;3"));
#else /* 0 or 1 */
  // This method should also work, I get these pointers initialized, but
  // then I get a "segmentation violation" in the "Draw" command below.
  // Always only the last call to "GetObject" gives a "valid" object,
  // pointers initialized before become "invalid".
  TH1F *TPCTOFEFFDeltapp, *TPCTOFEFFDeltamm, *TPCTOFEFFAverage;
  TPCTOFEfffile->GetObject("hEff;1", TPCTOFEFFDeltapp);
  TPCTOFEfffile->GetObject("hEff;2", TPCTOFEFFDeltamm);
  TPCTOFEfffile->GetObject("hEff;3", TPCTOFEFFAverage);
#endif /* 0 or 1 */
  
  TCanvas *d23 = new TCanvas("d23", "efficiency*acc", 0, 0, 950, 700);
  
  TPCTOFEFFDeltapp->Draw();
  TPCTOFEFFDeltamm->Draw("same");
  TPCTOFEFFAverage->Draw("same");
  
  d23->SaveAs("TPC_TOF_EFF_ACC.eps");
}

ayben · March 29, 2011, 6:54pm

Dear Pepe,

Thank you for the correction. FindObjectAny() does the job.

Cheers,

Ayben

Pepe_Le_Pew · March 29, 2011, 6:58pm

The real question is why “GetObject” fails.

pcanal · March 29, 2011, 8:26pm

TH1F* TPCTOFEFFDeltapp = (TH1F*)(TPCTOFEfffile->FindObject(hEff;1)) ;
TH1F* TPCTOFEFFDeltamm = (TH1F*)(TPCTOFEfffile->FindObject(hEff;2)) ;
TH1F* TPCTOFEFFAverage = (TH1F*)(TPCTOFEfffile->FindObject(hEff;3)) ;

is not recommended. When writing those histogram, we recommend that you store them with a different name. The cycle are intended to be various ‘revision’ of the same object and are used mostly for reliability (i.e. the older version is usually preserved until at least the complete successful storing of the new revision and hence is not lost in case of sudden interruption during the storing of the newer cycle). Most of the utilities in the TDirectory/TFile classes assumes this usage (for example Purge will remove the lowest cycles from the file).
In particular GetObject assumes that if one of the cycle has already been read, it is the one need for subsequent calls. FindObjectAny on the other hand, let’s you override this behavior and will always give the cycle you requested (as the expense of reading it from the file each time you request it). And FindObject should only find object that are already loaded and does not support name with cycles.

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 8:41pm

Thanks for your explanations about the “GetObject” behavior.
From my experience … ‘FindObject(“it”)’ fails to find it … ‘FindObjectAny(“it”)’ finds it.

pcanal · March 29, 2011, 8:51pm

Hi Pepe,

Indeed, in the previous I mean to talk about FindObjectAny (I went ahead and update the post accordingly).
FindObject will only find object that are already in memory (and those not support name with a cycle in them) while FindObjectAny will find both (but will find the in memory only if a cycle in not specified).

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 9:00pm

What is “FindObjectAnyFile” good for?
According to the short description it should scan all opened files for an object.
I try:

root [0] TFile *TPCTOFEfffile = TFile::Open("EFFTPCTOF.root", "read");
root [1] gROOT->cd();
root [2] gDirectory->FindObjectAnyFile("hEff")
(const class TObject*)0x0
root [3] TPCTOFEfffile->FindObjectAnyFile("hEff")
(const class TObject*)0x9ee6c30

pcanal · March 29, 2011, 9:02pm

According to the short description it should scan all opened files for an object.

the description is:

Scan the memory lists of all files for an object with name

i.e. it will find an object if and only if it has already been loaded in memory.

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 9:09pm

I seem to miss something …

root [...] TH1F *h;
root [...] TPCTOFEfffile->GetObject("hEff", h); // does this "load" this histogram?
root [...] gROOT->GetListOfFiles()->Print()
Collection name='Files', class='TList', size=1
 TFile: name=EFFTPCTOF.root, title=outputfile, option=READ
TH1.Print Name  = hEff, Entries= 67098, Total sum= 3.4977
root [...] gROOT->FindObjectAnyFile("hEff")
(const class TObject*)0x0
root [...] gROOT->FindObjectAny("hEff")
(const class TObject*)0x0
root [...] gROOT->FindObject("hEff")
(const class TObject*)0x9ee6c30

pcanal · March 29, 2011, 9:17pm

Hi,

Humm … indeed the version of FindObjectAnyFile in the TROOT class was inadvertently disable (always return zero), you need to call FindObjectAnyFile on ‘any’ TFile object to get the right answer. (TROOT::FindObjectAny in revision 38661 and higher of the trunk does return the correct answer).

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 9:20pm

Is the “peculiarity” of gROOT responsible also for not finding the object with “FindObjectAny” while this time “FindObject” works (see my previous post, I edited it a bit)?

pcanal · March 29, 2011, 9:27pm

Is the “peculiarity” of gROOT responsible also for not finding the object with “FindObjectAny”

Yes, TROOT::FindObjectAny (until today’s trunk) always returns 0.

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 9:43pm

Maybe one more question.
In another thread named “Draw the 2-D histograms which in the subFolder” someone had several (recursive) “TFolder” objects with histograms (in a file). Then no call to ‘file->FindObject…(“histogram”)’ was able to find the “histogram”.
I needed to manually call ‘top_level_file_TFolder->FIndObjectAny(“histogram”)’ and then it was able to recursively traverse these folders and find required objects.
I would rather expect that “file->Find…()” was recursively traversing any present (file resident) TDirectory and TFolder inside.

pcanal · March 29, 2011, 9:48pm

Hi,

As far as TDirectory is concerned, TFolder is an opaque object without any structure and thus it can not (and should not) load nor try to traverse it ; this is left to the user. When needing an organization where TDirectory::FindObject… should find the objects then you should use TDirectory instead of TFolder.

Cheers,
Philippe.

Pepe_Le_Pew · March 29, 2011, 9:53pm

O.K. I understand now why a TDirectory does not traverse any found TFolder based structures.
However, the TFolder itself still knows how to recursively traverse TFolder based “subdirectory structures”.
I don’t know what happens when a TFolder traverse finds a TDirectory inside - it probably skips it, too (well, I’m too lazy to test it).
Thanks for your explanations.