Hi,
I have a root file created with root 6.18/04
I can use this file and Draw any quantities with the command line without problems
When trying to loop on Entries I get a lot (but not for every entries) messages:
Error R__unzip_header: error in header. Values: 064
Error in <TBasket::ReadBasketBuffers>: Inconsistency found in header (nin=0, nbuf=0)
Error in <TBasket::ReadBasketBuffers>: fNbytes = 111, fKeylen = 75, fObjlen = 1656, noutot = 0, nout=0, nin=0, nbuf=0
In this file there is a unusual branch that could be the case of the problem but
a Draw using this branch show no problems and no messages.
Hi @produit,
do I understand correctly that you are reading a file produced with ROOT v6.18 with ROOT v6.04? Thatās a very old ROOT version, could that be causing of the problem? E.g. can you read the file correctly with a recent ROOT version on lxplus?
Hi,
I am using 6.18/04 for both writing and reading.
Sorry for the confusion.
produit@yoga2$ root
------------------------------------------------------------
| Welcome to ROOT 6.18/04 https://root.cern |
| (c) 1995-2019, The ROOT Team |
| Built for linuxx8664gcc on Dec 05 2019, 16:25:00 |
| From tags/v6-18-04@v6-18-04 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------
Hi,
I have not worked on this since Friday afternoon, sorry.
Iām still hoping @pcanal could comment, because Iām not sure what could cause messages like
Error R__unzip_header: error in header. Values: 064
Error in <TBasket::ReadBasketBuffers>: Inconsistency found in header (nin=0, nbuf=0)
Error in <TBasket::ReadBasketBuffers>: fNbytes = 111, fKeylen = 75, fObjlen = 1656, noutot = 0, nout=0, nin=0, nbuf=0
Some of the basket of the branch āped_idā are in corrupted part of the file.
The difference between the āno warning printedā and āwarning printedā case lay in
int n = t->GetEntries();
for (int i = 0; i < n; i++) {
t->GetEntry(i);
reads all the branches even-though you only need/access two.
In contrast TTree::Draw will read only the branches needed.
You can try RDF or the following tweak on your code:
UShort_t waveform[148400];
TBranch *waveform_b = nullptr;
t->SetBranchAddress("waveform", waveform, &waveform_b);
UInt_t trigger_time_s;
TBranch *trigger_time_s_b = nullptr;
t->SetBranchAddress("trigger_time_s", &trigger_time_s, &trigger_time_s_b);
UInt_t trigger_time_qns;
TBranch *trigger_time_qns_b;
t->SetBranchAddress("trigger_time_qns", &trigger_time_qns, &trigger_time_qns_b);
int n = t->GetEntries();
for (int i = 0; i < n; i++) {
Long64_t local_entry = t->LoadEntry(i); // returns the local entry number of the current tree in branch.
waveform_b->GetEntry(local_entry);
trigger_time_s_b->GetEntry(local_entry);
trigger_time_qns_b->GetEntry(local_entry);
(technically you only need the last 2 entry if at least one of the element of the waveform array for the current entry passes the cut.)
Hi Philippe,
thanks a lot.
The question now is why this file is corrupted in the first place.
This file is created using root 6.18/04.
I can recreate the file and reproduce the problem so it is not something due to after the fact file
corruption. So how come can we create a corrupted file.
It is possible that the program that write the file has a bug but I donāt know exactly what I have to look for. At least there are no compiler warnings nor messages during execution.
You said the problem is in the ped_id branch, I can try to see if there is something special with this branch.
The program that create the file is a very generic program that transform file in ZFITS format into ROOT
so it is very general so not easy to make something smaller that reproduce the creation problem.
But I can 100% reproduce the problem in converting a particular ZFITS file using this program
Looking at the error more carefully, it looks like the problem is āonlyā the 2nd basket of the āped_idā branch. Specifically it appears to be a compression problem. It is possible (but not guaranteed) that the basket compression failed and the raw data was stored (uncompressed) but marked as being compressed.
Either way, since this is reproducible and happening exactly once, with the reproducer and a debug version of ROOT we ought to be able to understand the problem.