Thanks for the help/tip, Rene. I have done this map for two
files. One shows an error before the end of file. The other one
does not. So now I'm left wondering what the problem with
that file is.
Both files, however, show a number of messages with "GAP".
What is a gap, and is it a problem?
-Gene
-----Original Message-----
From: Rene Brun
To: Van Buren, Gene
Cc: roottalk@pcroot.cern.ch
Sent: 4/6/02 10:00 AM
Subject: Re: [ROOT] Consequences of basket read errors
Hi Gene,
In the CVS source, I have modified the GetEntry functions to return -1
in case an errors occurs when reading one branch basket.
You can test the GetEntry return value.
This case may happen when the file has been overwritten or truncated.
To check if this is the case, you can do the following:
TFile f("myfile.root");
f.Map(); > f.log
You can inspect the f.log file to see if the end of the file
has been successfully reached or not.
Rene Brun
On Fri, 5 Apr 2002, Gene Van Buren wrote:
> Hi, I wanted to find out if anyone knows the consequences
> of the following error when reading a TTree from a file:
>
> Error in <TBranchElement::GetBasket>: File: someFile.root at byte:0,
> branch:myBranch.myElement, entry:3304
>
> This error is produced at line 600 of TBranch.cxx in Root
> version 3.03/03. I used the debugger to find that the error
> comes from a problem with reading in a record header.
> The failure to read the record header causes the TBasket
> used to have zero for the record size (nbytes) and seekkey,
> but produces no other errors.
>
> I am guessing that the error occurs because of a corruption
> to the actual file on disk. Is this a valid assumption, and if
> not, how would one be sure?
>
> What happens subsequently is that ROOT keeps on
> running (getting a few of these errors in a row, but only
> a few and then they stop). Because most of that TTree
> "entry" or "event" still seems to read in OK, the number
> of bytes returned for reading in looks reasonable, and
> I have no way other than this error message to know
> that something went wrong.
>
> But. as ROOT continues from this point in the TTree file
> onwards, _something_ has definitely gone wrong. I don't
> _see_ anything obviously wrong in the data that is being
> read in by from a casual glance. However, the size of my
> ROOT executable starts a dramatic upwards climb until
> it crashes from exhausting memory after a short while.
> (memory usage appears completely stable before this
> error).
>
> So, I'm wondering if there's a way I can "catch" problems
> like this and stop my processes from bogging down the
> computer until the ROOT process crashes. And I'm
> also wondering if there's a way to determine if the
> problem is definitely with a corruption to the file (without
> trying to re-create the file).
>
> Thanks,
>
> -Gene Van Buren
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:48 MET