Hi,
See TTree::ChangeFile which may be triggered in your case. You may have to increase increase the default limit
TTree::SetMaxTreeSize(very_large_number); or allocate the TFile on the stack reather than heap.
Cheers,
Philippe.
-----Original Message-----
From: owner-roottalk_at_root.cern.ch [mailto:owner-roottalk_at_root.cern.ch] On
Behalf Of Arthur E. Snyder
Sent: Thursday, June 12, 2008 10:16 AM
To: Arthur E. Snyder
Cc: roottalk_at_lxbuild091.cern.ch
Subject: [ROOT]TFile crash in ~TFile
I get a segmentation violation in ~TFile as it is trying to close my file. The trace back is below.
The line pointed to in my code is 985. However, the error appears to not during |write| but when the TFile is destroyed on leave this scope at the "}".
Other identical jobs run fine. This is the largest data set processed. It worked previously; here I've just added a few more items to output n-tuple for a total of 32. There are 47G available where it's being written which should be plenty and in any case it's seg violation not a out of space error.
Any ideas?
-Thanks, Art S.
code snip:
for(Int_t i=0; i<nHist; i++) {
if(h[i]==0) continue; h[i]->Write(); } //write out the n-tuple tup->write(); <---line 985}
trace back:
#16 0x014da328 in HiggsFinder::Terminate (this=0xa546af0)
at HiggsFinder.cc:985 <----mycode
#17 0x05735dd3 in TTreePlayer::Process (this=0xab211d8, selector=0xa546af0,
option=0x4020330 "", nentries=1234567890, firstentry=0) at treeplayer/src/TTreePlayer.cxx:2664 #18 0x03f77184 in TTree::Process (this=0xae4c190, selector=0xa546af0, option=0x4020330 "", nentries=1234567890, firstentry=0) at tree/src/TTree.cxx:4793 #19 0x03f4ba53 in TChain::Process (this=0xae4c190, selector=0xa546af0, option=0x4020330 "", nentries=1234567890, firstentry=0) at tree/src/TChain.cxx:1750
from
/afs/slac.stanford.edu/g/babar/package/root/5.14-00e/Linux24SL3_i386_gcc323-
noOptimize-Debug/lib/libTree.so
#21 0x00f13ca5 in Cint::G__ExceptionWrapper (
funcp=0x3fc8f74 <G__G__Tree_224_0_56(G__value*, char const*, G__param*, int)>, result7=0xbffe43e0, funcname=0xa176658 "\001", libp=0xbffe0e00, hash=0)
at cint/src/Api.cxx:355
#22 0x00fd9922 in G__call_cppfunc (result7=0xbffe43e0, libp=0xbffe0e00,
ifunc=0xa176658, ifn=0) at cint/src/v6_newlink.cxx:465 #23 0x00fc3b04 in G__interpret_func (result7=0xbffe43e0,
funcname=0xbffe3fe0 "Process", libp=0xbffe0e00, hash=735, p_ifunc=0xa176658, funcmatch=1, memfunc_flag=1) at cint/src/v6_ifunc.cxx:5167 #24 0x00fac1ab in G__getfunction (item=0xbffe6806 "Process(finder)", known3=0xbffe5c1c, memfunc_flag=1) at cint/src/v6_func.cxx:2600 #25 0x0105d357 in G__getstructmem (store_var_type=112, varname=0xbffe5880 "U", membername=0xbffe6806 "Process(finder)", tagname=0xbffe4be0 "toff", known2=0xbffe5c1c, varglobal=0x10e1ac0, objptr=2) at cint/src/v6_var.cxx:4284 #26 0x01052bf2 in G__getvariable (item=0xbffe6800 "toff->Process(finder)", known2=0xbffe5c1c, varglobal=0x10e1ac0, varlocal=0xbfff1cf0) at cint/src/v6_var.cxx:3129 #27 0x00fa06ea in G__getitem (item=0xbffe6800 "toff->Process(finder)") at cint/src/v6_expr.cxx:1846
at cint/src/v6_expr.cxx:1315
#29 0x00ff7c5d in G__exec_function (
statement=0xbffe7d90 "toff->Process(finder)", pc=0xbffe7d8c, piout=0xbffe7d80, plargestep=0xbffe7d70, presult=0xbffe8190) at cint/src/v6_parse.cxx:457 #30 0x01001352 in G__exec_statement () at cint/src/v6_parse.cxx:4211 #31 0x00ffc53f in G__exec_if () at cint/src/v6_parse.cxx:2480#32 0x01000db2 in G__exec_statement () at cint/src/v6_parse.cxx:4102 #33 0x00fc5d7e in G__interpret_func (result7=0xbfff58e0,
funcname=0xbfff54e0 "batch", libp=0xbfff2300, hash=514, p_ifunc=0xa415570, funcmatch=1, memfunc_flag=0) at cint/src/v6_ifunc.cxx:5954 #34 0x00faca9e in G__getfunction (item=0xbfff6670 "batch()", known3=0xbfff5a8c, memfunc_flag=0) at cint/src/v6_func.cxx:2813 #35 0x00fa0781 in G__getitem (item=0xbfff6670 "batch()") at cint/src/v6_expr.cxx:1859 #36 0x00f9ed46 in G__getexpr (expression=0x9d7c960 "batch()") at cint/src/v6_expr.cxx:1315 #37 0x00f91f67 in G__calc_internal (exprwithspace=0xbfff8f70 "batch()") at cint/src/v6_expr.cxx:203 #38 0x0100878b in G__process_cmd ( line=0xe56cb2 ".X
rslt=0xbfff97d0) at cint/src/v6_pause.cxx:2310 #39 0x0089d757 in TCint::ProcessLine (this=0x9abdd68,
line=0xe56cb2 ".X
/afs/slac.stanford.edu/u/ek/snyder/trial41/analysis-42/workdir/./batch.C",
error=0xbfffa0e4) at meta/src/TCint.cxx:318
#40 0x0089d8dc in TCint::ProcessLineSynch (this=0x9abdd68,
line=0xe56cb2 ".X
/afs/slac.stanford.edu/u/ek/snyder/trial41/analysis-42/workdir/./batch.C",
error=0xbfffa0e4) at meta/src/TCint.cxx:351
#41 0x007a2de3 in TApplication::ProcessFile (this=0x9aff010,
name=0xbfff9f23 "batch.C", error=0xbfffa0e4) at base/src/TApplication.cxx:807 #42 0x007a2553 in TApplication::ProcessLine (this=0x9aff010, line=0xbfff9f20 ".x batch.C", sync=false, err=0xbfffa0e4) at base/src/TApplication.cxx:676 #43 0x0062087e in TRint::Run (this=0x9aff010, retrn=false) at rint/src/TRint.cxx:328
A.E. Snyder, Group EC \!c*p?/ SLAC Mail Stop #95 ((. .)) Box 4349 | Stanford, Ca, USA, 94309 '\|/` e-mail:snyder_at_slac.stanford.edu o phone:650-926-2701 _ http://www.slac.stanford.edu/~snyder BaBar FAX:650-926-2657 CollaborationReceived on Thu Jun 12 2008 - 17:28:16 CEST
This archive was generated by hypermail 2.2.0 : Thu Jun 12 2008 - 23:50:02 CEST