Hi Edward,
Your files rad1.root and bch6.root are empty. The TTree objects report that they have 0 entries.
The most likely cause is that in filterTree.cc you have:
} // End of filter loop.
newfile->Close();
delete newfile;
which means that you are NOT saving the TTree meta-data.
Make sure to do so by doing:
} // End of filter loop.
newfile->Write();
newfile->Close();
delete newfile;
Cheers,
Philippe.
-----Original Message-----
From: Edward Chen [mailto:edward@SLAC.Stanford.EDU]
Sent: Friday, August 15, 2003 11:53 AM
To: Philippe Canal
Cc: Rene Brun; roottalk@pcroot.cern.ch
Subject: RE: [ROOT] Problem with filtering tree
Hi - it looks like setting these arrays sizes much larger solves that
particular problem.
Now - it appears that my filtering does not work correctly. Three example
product files:
(1)
http://www.hep.caltech.edu/~edward/08152003/esig.root
Expect 45223 evts, get 36010.
e.g. ntp1->Draw("nBump");
(2)
http://www.hep.caltech.edu/~edward/08152003/bch6.root
Expect 615, get 0.
(3)
http://www.hep.caltech.edu/~edward/08152003/rad1.root
Expect 6, get 0.
The code is at:
http://www.hep.caltech.edu/~edward/08152003/filterTree.cc
Thanks for your help.
-Ed
On Thu, 14 Aug 2003, Philippe Canal wrote:
> Hi Edward,
>
> You problem is then that the arrays which are followed by the comment
> //[nBump]
> are too small. This leads to memory over-write, which leads to
> unpredicatble
> behavior. Increase the size of those array to the highest value of nBump in
> your files.
>
> Cheers,
> Philippe.
>
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
> [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Edward Chen
> Sent: Thursday, August 14, 2003 7:08 AM
> To: Rene Brun
> Cc: roottalk@pcroot.cern.ch
> Subject: Re: [ROOT] Problem with filtering tree
>
>
> Hi Rene - I added the following lines to my code:
>
> // oldtree->GetEntry(i); // This line given for context
>
> if (nCand > 10) cout << "nCand is greater than 10 for " << i << endl;
> if (nBump > 75) cout << "nBump is greater than 75 for " << i << endl;
> if (nKlongEmc > 50) cout << "nKlongEmc is greater than 50 for " << i
> << endl;
> if (nKlongIfr > 50) cout << "nKlongIfr is greater than 50 for " << i
> << endl;
>
> Now - with these simple additions, I get some weird effects. One chain
> file which had filtering problems ran completely through. Another one,
> instead
> of crashing at ~20K events, crashes at around 610K events. Here's some
> output:
>
> The total counter = 540000
> The total counter = 550000
> nBump is greater than 75 for 558948
> The total counter = 560000
> The total counter = 570000
> The total counter = 580000
> The total counter = 590000
> The total counter = 600000
> The total counter = 610000
>
> Any ideas? Thanks.
>
> -Ed
>
> On Thu, 14 Aug 2003, Rene Brun wrote:
>
> > Hi Ed,
> >
> > I see that you have many local arrays with dimension [10]. These arrays
> > may have [nCand] elements. Are you sure that in some of your files/chains,
> > nCand is not greeater than 10.
> > When using TTree::MakeCode, the maximum dimension is calculated based
> > on the maximum dimension in the Tree used to generate the code.
> >
> > Let me know
> >
> > Rene Brun
> >
> > Edward Chen wrote:
> > >
> > > Hi - this is a bit of a followup to some tree-filtering problems I had a
> > > while back, using ROOT v3.04/02.
> > >
> > > I have a large set of root files each with the same types of ntuples.
> > > These files are chained together in sets of chain files. For example,
> for
> > > one sample, I have 14 chain files, corresponding to about 12.5 million
> > > events each.
> > >
> > > I have successfully run code based on classes created via MakeSelector()
> > > on these chain files.
> > >
> > > I'm now trying to filter each chain file into a single root file, using
> > > the following:
> > >
> > > http://www.hep.caltech.edu/~edward/filterTree.cc
> > >
> > > The filtering seems to work successfully for some of my chain files, but
> > > crashes while running in the middle of some other chain files. Here is
> > > the stack trace (crash appears to occur after about 20K events):
> > >
> > > *** Break *** segmentation violation
> > > Generating stack trace...
> > > 0x401ae93b in TUnixSystem::StackTrace(void) + 0x25b from
> > > /home/edward/root/lib/libCore.so
> > >
> > > 0x401ad5ba in TUnixSystem::DispatchSignals(ESignals) + 0xb2 from
> > > /home/edward/root/lib/libCore.so
> > > 0x401ac763 in <unknown> from /home/edward/root/lib/libCore.so
> > > 0x401b01fd in <unknown> from /home/edward/root/lib/libCore.so
> > > 0x40c258d5 in <unknown> from /lib/i686/libpthread.so.0
> > > 0x40cc5848 in <unknown> from /lib/i686/libc.so.6
> > > 0x40acb293 in TChain::GetEntry(int, int) + 0x17 from
> > > /home/edward/root/lib/libTree.so
> > > 0x40af30a0 in <unknown> from /home/edward/root/lib/libTree.so
> > > 0x40596b8a in G__exec_asm + 0x8ee from /home/edward/root/lib/libCint.so
> > > 0x40589349 in G__exec_loop + 0x53d from
> /home/edward/root/lib/libCint.so
> > > 0x405897c5 in G__exec_for + 0x255 from /home/edward/root/lib/libCint.so
> > > 0x4058c6b6 in G__exec_statement + 0x2c06 from
> > > /home/edward/root/lib/libCint.so
> > > 0x4055f79c in G__interpret_func + 0x20fc from
> > > /home/edward/root/lib/libCint.so
> > > 0x40544728 in G__getfunction + 0x1bb4 from
> > > /home/edward/root/lib/libCint.so
> > > 0x4053c0c9 in G__getitem + 0x509 from /home/edward/root/lib/libCint.so
> > > 0x4053a863 in G__getexpr + 0x8ba3 from /home/edward/root/lib/libCint.so
> > > 0x405319a2 in G__calc_internal + 0x38e from
> > > /home/edward/root/lib/libCint.so
> > > 0x40592267 in G__process_cmd + 0x23eb from
> > > /home/edward/root/lib/libCint.so
> > > 0x401710ba in TCint::ProcessLine(char const *, TInterpreter::EErrorCode
> > > *) + 0x9a from /home/edward/root/lib/libCore.so
> > > 0x401711a8 in TCint::ProcessLineSynch(char const *,
> > > TInterpreter::EErrorCode *) + 0x48 from /home/edward/root/lib/libCore.s
> > > o
> > > 0x40107bb6 in TApplication::ProcessFile(char const *, int *) + 0x6e2
> from
> > > /home/edward/root/lib/libCore.so
> > > 0x40107320 in TApplication::ProcessLine(char const *, bool, int *) +
> > > 0x4ec from /home/edward/root/lib/libCore.so
> > > 0x40bec45b in TRint::HandleTermInput(void) + 0x127 from
> > > /home/edward/root/lib/libRint.so
> > > 0x40beb780 in TTermInputHandler::Notify(void) + 0x28 from
> > > /home/edward/root/lib/libRint.so
> > > 0x40bfb853 in TTermInputHandler::ReadNotify(void) at
> > > /usr/src/build/85131-i386/BUILD/glibc-2.2.4/stdlib/atexit.c:33 from /h
> > > ome/edward/root/lib/libRint.so
> > > 0x401ad9af in TUnixSystem::CheckDescriptors(void) + 0x113 from
> > > /home/edward/root/lib/libCore.so
> > > 0x401ad0c2 in TUnixSystem::DispatchOneEvent(bool) + 0x112 from
> > > /home/edward/root/lib/libCore.so
> > > 0x4014a669 in TSystem::InnerLoop(void) + 0x1d from
> > > /home/edward/root/lib/libCore.so
> > > 0x4014a5fe in TSystem::Run(void) + 0x7e from
> > > /home/edward/root/lib/libCore.so
> > > 0x40107f2d in TApplication::Run(bool) + 0x31 from
> > > /home/edward/root/lib/libCore.so
> > > 0x40bebf96 in TRint::Run(bool) + 0x2ba from
> > > /home/edward/root/lib/libRint.so
> > > 0x08048802 in main + 0x52 from /home/edward/root/bin/root.exe
> > > 0x40cb3507 in __libc_start_main at
> > >
> /usr/src/build/40457-i686/BUILD/glibc-2.2.4/csu/../sysdeps/generic/libc-star
> t.c:129
> > > from
> > > /lib/i686/libc.so.6
> > > 0x080486d1 in __register_frame_info + 0x35 from
> > > /home/edward/root/bin/root.exe
> > > Function filterTree() busy flag cleared
> > >
> > > *** Break *** segmentation violation
> > > Generating stack trace...
> > > Terminated
> > >
> > > The problem seems to be in GetEntry() - however - my selector classes
> also
> > > use GetEntry() on these chain files with no problems.
> > >
> > > Thanks for any help.
> > >
> > > -Ed
> >
>
>
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:14 MET