Re: [ROOT] TTree::Streamer

From: Rene Brun (Rene.Brun@cern.ch)
Date: Sun Feb 10 2002 - 11:05:03 MET


Hi Sue,

The problem is fixed in the CVS version. 

I had already found the problem from my remote place, but could
not commit the changes because the CERN netweork was closed yesterday.
The same problem had been reported by Glen Salo

The problem was that the Tree was added to the THashList in the current
directory before reading the name of the Tree.

Rene


On Sat, 9 Feb 2002, Susan Kasahara wrote:

> Hi root team,
> I have been experiencing a segv in our framework since
> upgrading to root cvs version 2002-02-04.  This segv
> occurs when closing a root file from which trees have
> been read.
> The stack dump is appended.  The segv appears in
> a call to TObjectTable::Delete from TCollection::EmptyGarbageCollection
> when closing the file.
>    I have not been able to isolate a simple example
> from our code to submit as an example to this list,
> but I have been able to isolate the exact lines
> of code in ROOT that changed between the beginning of
> 2002-02-03 and 2002-02-04 to produce this problem in
> our framework.  The change was that two lines in
> TTree::Streamer were shifted from one place to another
> as shown in the commented version of TTree::Streamer
> below:
> 
> void TTree::Streamer(TBuffer &b) {
>    if (b.IsReading()) {
>       UInt_t R__s,R__c;
>       gTree = this;
>       Version_t R__v = b.ReadVersion(&R__s,&R__c);
>       if(R__v > 4) {
>         // The following 2 lines were moved here from the
>         // location below on 2002-02-03 17:30
>         // This causes a new problem with segv in our framework when
>         // closing the file from which the trees were read.
>         fDirectory = gDirectory;
>         gDirectory -> Append(this);
>         TTree::Class()->ReadBuffer(b, this, R__v, R__s, R__c);
>         if(fEstimate <= 10000) fEstimate = 1000000;
>         fSavedBytes = fTotBytes;
>         // Former location of 2 lines of code:
>         // fDirectory = gDirectory;
>         // gDirectory -> Append(this);
>         return;
>       }
>    ....
> I can fix the segv in our framework just by shifting the
> two lines back to their original position, but
> I'm wondering if it makes sense that the move of these two
> lines could potentially cause a problem.
> I appreciate any help you can give me in sorting this out.
> -Sue
> p.s. I am experiencing the segv on root cvs 2002-02-04
>       to 2002-02-09 (today), running on intel x86 linuxegcs
>       platform with gcc 2.96
> 
> #0  0x413c4a01 in __kill () from /lib/i686/libc.so.6
> #1  0x40f765bb in raise (sig=6) at signals.c:65
> #2  0x413c5f82 in abort () at ../sysdeps/generic/abort.c:88
> #3  0x40435b7f in TUnixSystem::Abort () at unix/src/TUnixSystem.cxx:1170
> #4  0x40434963 in TUnixSystem::DispatchSignals (this=0x8571658,
>      sig=kSigSegmentationViolation) at unix/src/TUnixSystem.cxx:554
> #5  0x40433871 in SigHandler (sig=kSigSegmentationViolation)
>      at unix/src/TUnixSystem.cxx:209
> #6  0x404371af in sighandler (sig=11) at unix/src/TUnixSystem.cxx:1942
> #7  0x40f768d5 in pthread_sighandler (signo=11, ctx=
>        {gs = 7, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 
> 3221221188, esi = 142414536, ebp = 3221220264, esp = 3221220256, ebx = 1080700000, edx = 324, ecx = 
> 142414536, eax = 0, trapno = 14, err = 6, eip = 1077884440, cs = 35, __csh = 0, eflags = 66182, 
> esp_at_signal = 3221220256, ss = 43, __ssh = 0, fpstate = 0xbfffe920, oldmask = 2147483648, cr2 = 324})
>      at signals.c:97
> #8  <signal handler called>
> #9  0x403f3618 in TObjectTable::Delete (this=0x87d12c8)
>      at cont/src/TObjectTable.cxx:199
> #10 0x403eaf48 in TCollection::EmptyGarbageCollection ()
>      at cont/src/TCollection.cxx:396
> #11 0x4039aadd in TFile::Close (this=0x86f11b0) at base/src/TFile.cxx:523
> #12 0x4004c76f in PerFile::Close (this=0x86f1190, kForce=false)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerFile.cxx:111
> #13 0x4004d3f3 in PerFileManager::CloseFile (this=0x86f1178,
>      fullfilepathname=0xbfffecb0)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerFileManager.cxx:76
> #14 0x400564a6 in PerStream::CloseFile (this=0x86f1130)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerStream.cxx:67
> #15 0x4004ddee in PerInputStream::CloseFile (this=0x86f1130)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerInputStream.cxx:68
> #16 0x40056bdf in PerStreamManager::CloseFile (this=0xbfffee30,
>      streamname=0xbfffed80)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerStreamManager.cxx:53
> #17 0x40050b14 in PerInputStreamManager::CloseFile (this=0xbfffee30,
>      streamName=0xbfffedb0)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/PerInputStreamManager.cxx:210
> #18 0x40092984 in DemoInputModule::EndFile (this=0xbfffee30,
>      streamname=0xbfffee00)
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/test/DemoInputModule.cc:91
> #19 0x0804ad16 in main ()
>      at /data/minos2/kasahara/minossoft/packages/Persistency/development/test/DemoInput.cc:64
> #20 0x413b2507 in __libc_start_main (main=0x804a940 <main>, argc=1,
>      ubp_av=0xbfffef44, init=0x804a594 <_init>, fini=0x804c810 <_fini>,
>      rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbfffef3c)
>      at ../sysdeps/generic/libc-start.c:129
> 



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:41 MET