Re: a strange behavior in TTree::ChangeFile

From: Kazuyoshi Furutaka <furutaka_at_jb3.so-net.ne.jp>
Date: Wed, 04 Apr 2007 00:05:56 +0900 (JST)


Dear Rene and rooters,

Thanks Rene for your quick reply.

I've inserted a line doing TTree::GetCurrentFile() before Write()ing and then the problem disappeared.

Yours,
Kazuyoshi

From: Rene Brun <Rene.Brun_at_cern.ch>
Subject: Re: [ROOT] a strange behavior in TTree::ChangeFile Date: Tue, 03 Apr 2007 16:30:25 +0200

> I am suspecting a problem when closing the last file.
> See important remark in the documentation of TTree::ChangeFile at:
> http://root.cern.ch/root/htmldoc/TTree.html#TTree:ChangeFile
>
> Rene Brun
>
> Kazuyoshi Furutaka wrote:
> > Dear rooters,
> >
> > I wrote a routine which loops over filling
> > of a TTree consisting of about 40 C-style
> > struct data (2 UShort_t's and a Float_t)
> > and store the TTree in a .root file.
> >
> > When the size of the file exceeds about
> > 1.9GB, TTree::ChageFile is called; just
> > after the call a segmentation fault occurs.
> > The size of the .root file is 1903347510 bytes.
> >
> > If I break the filling loop before the file
> > grows larger enough (say about a few thousand
> > of the data), the error doesn't occur.
> >
> > Also, if I double the max tree size
> > (TTree::SetMaxTreeSize(3800000000)),
> > it works without SegV.
> >
> > How can I avoid the error without increasing
> > the tree size?
> > I'll appreciate any suggestions.
> >
> > The attached is a part of a backtrace of a gdb
> > session.
> >
> > My environment is:
> > Linux, Fedora Core release 6 (Zod), running
> > kernel 2.6.20-1.2933.fc6 #1 SMP
> > on a Core 2 Duo machine (i386).
> > Root Version 5.15/04, built with
> > g++ (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51).
> > (The routine was also compiled using the
> > ACLiC.)
> >
> > Thanks in advance.
> >
> > Yours,
> > Kazuyoshi
> > --
> > Kazuyoshi Furutaka
> > furutaka_at_jb3.so-net.ne.jp
Received on Tue Apr 03 2007 - 17:06:05 CEST

This archive was generated by hypermail 2.2.0 : Wed Apr 04 2007 - 05:50:01 CEST