RE: TFile crash in ~TFile

I'm running it now .. at least it's different from what I was doing.

I looked up heap vs. stack on google, but the discussions I found only had to the confusion. Anyway I'm of the 'whatever works' schools, so I'll just try it whatever it's called.

-Art

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                          Collaboration

On Thu, 12 Jun 2008, Philippe Canal wrote:

> Hi Art,
>
> Yes it is still (possibly) wrong(for the details see the documentation of
> TTree::ChangeFile).
>
> You should try:
>
> TFile* pOutput=new TFile(fileName,"new");
>
> write stuff
>
> delete tree->GetFile();
>
> Cheers,
> Philippe.
>
> -----Original Message-----
> From: Arthur E. Snyder [mailto:snyder_at_slac.stanford.edu]
> Sent: Thursday, June 12, 2008 3:44 PM
> To: Rene Brun
> Cc: Philippe Canal; roottalk_at_lxbuild091.cern.ch
> Subject: Re: [ROOT]TFile crash in ~TFile
>
> I was previously doing
>
> TFile output(fileName,"new");
>
> write stuff
>
> then leave scope.
>
> This is what crashed.
>
> and changed it to
>
> TFile* pOutput=new TFile(fileName,"new");
>
> write stuff
>
> delete pOutput
>
> leave scope.
>
> Is that wrong?
>
> -Art S.
>
> 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 Collaboration
>
>
>
> On Thu, 12 Jun 2008, Rene Brun wrote:
>
>> NO !! When creating an object with new the object is allocated in the
> heap.
>>
>> Rene Brun
>>
>> Arthur E. Snyder wrote:
>>> "on stack" means use "new", right?
>>>
>>> -Art
>>>
>>> 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 Collaboration
>>>
>>>
>>>
>>> On Thu, 12 Jun 2008, Philippe Canal wrote:
>>>
>>>> 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:
>>>> *** Break *** segmntation violation
>>>> Using host libthread_db library "/lib/tls/libthread_db.so.1".
>>>> Attaching to program: /proc/26766/exe, process 26766
>>>> [Thread debugging using libthread_db enabled]
>>>> [New Thread 1073746912 (LWP 26766)]
>>>> 0x0394e51e in __waitpid_nocancel () from /lib/tls/libc.so.6
>>>> Thread 1 (Thread 1073746912 (LWP 26766)):
>>>> #0 0x0394e51e in __waitpid_nocancel () from /lib/tls/libc.so.6
>>>> #1 0x038e31d4 in do_system () from /lib/tls/libc.so.6
>>>> #2 0x01cd7d7f in system () from /lib/tls/libpthread.so.0
>>>> #3 0x00948d6e in TUnixSystem::Exec (this=0x9ab1430,
>>>> at unix/src/TUnixSystem.cxx:1768
>>>> #4 0x00949208 in TUnixSystem::StackTrace (this=0x9ab1430)
>>>> at unix/src/TUnixSystem.cxx:1953
>>>> #5 0x00947147 in TUnixSystem::DispatchSignals (this=0x9ab1430,
>>>> sig=kSigSegmentationViolation) at unix/src/TUnixSystem.cxx:936
>>>> #6 0x00945369 in SigHandler (sig=kSigSegmentationViolation)
>>>> at unix/src/TUnixSystem.cxx:338
>>>> #7 0x0094bcda in sighandler (sig=11) at unix/src/TUnixSystem.cxx:3142
>>>> #8 <signal handler called>
>>>> #9 0x039db79b in main_arena () from /lib/tls/libc.so.6
>>>> #10 0x007c4b5a in TDirectory::WriteKeys (this=0xbffd6ac0)
>>>> at base/src/TDirectory.cxx:1951
>>>> #11 0x007c30a6 in TDirectory::SaveSelf (this=0xbffd6ac0, force=false)
>>>> at base/src/TDirectory.cxx:1452
>>>> #12 0x007c2eda in TDirectory::Save (this=0xbffd6ac0)
>>>> at base/src/TDirectory.cxx:1413
>>>> #13 0x007bfa20 in TDirectory::Close (this=0xbffd6ac0)
>>>> at base/src/TDirectory.cxx:500
>>>> #14 0x007cd7d0 in TFile::Close (this=0xbffd6ac0, option=0xc8b3ba "")
>>>> at base/src/TFile.cxx:716
>>>> #15 0x007cba9c in TFile::~TFile () at include/TInetAddress.h:69
>>>>
>>>> #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
>>>> #20 0x03fc9223 in G__G__Tree_224_0_56 ()
>>>> 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
>>>> #28 0x00f9ed46 in G__getexpr (expression=0xbffe7d90
>>>> "toff->Process(finder)")
>>>> 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
>>>>
> /afs/slac.stanford.edu/u/ek/snyder/trial41/analysis-42/workdir/./batch.C",
>>>> prompt=0x9abdd8c "", more=0x9abdd84, err=0xbfff97cc,
>>>> 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
>>>> #44 0x0804894e in main (argc=1, argv=0xbfffa1c4) at
> main/src/rmain.cxx:29
>>>> Function batch() busy flag cleared
>>>>
>>>> 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 Collaboration
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Received on Thu Jun 12 2008 - 23:41:39 CEST