Hi David, We have no time-out logic when reading in ROOT itself. Time-out should be in NFS. One could consider adding a "retry" call in case the TFile read function returns 0 bytes. It would be nice if you could try this small addition and test it with your configuration. Let me know. Rene Brun On Tue, 25 Jun 2002, David R. Relyea wrote: > Before I upgrade ROOT here (since I have to get someone here at SLAC to do > that, and they're difficult to find), may I ask a little more? > > We have determined that the crashes are caused by the poor performance of > an NFS server at SLAC - when it pegs (it has a very slow network card), we > see this problem. On other servers, I get no such errors, since they can > handle the traffic. It's as if there's a timeout on a read function > somwhere (returning zero bytes, causing the R__unzip error). Can ROOT > time out on reads? (we're trying to isolate the source of the timeout) > And if so, what's the value of the timeout? > > David Relyea > > > On Sun, 23 Jun 2002, Rene Brun wrote: > > Hi David, > > Could you try with version 3.03/06? > We fixed a problem in February in some special cases of branch > buffers when the compressed buffer is bigger (yes) than the > uncompressed buffer. > > Rene Brun > > On Sat, 22 Jun 2002, David R. Relyea wrote: > > > I have a large subroutine which opens three trees and loops through all > > three (all the same length) multiple times. I use SetBranchAddress and > > GetEntry only (no other tree subroutines called). About 50% of the time, > > this subroutine works. The other 50% of the time, it seg faults after > > having given me this kind of error (thousands of times): > > > > R__unzip: discrepancy with initial size > > Error in <TBasket::ReadBasketBuffers>: fObjlen = 31936, nout = 0 > > Error in <TBranch::GetBasket>: File problem at address:50142285, basket > > seekkey=50142285, branch:cep00 > > > > The error is non-reproducible - it's a random occurrence, as far as I can > > tell. Where does the R__unzip come from? Looking through roottalk, it > > seems as if it should only occur on odd zero-length files (trees?), and > > I'm positive I have none (this routine works 50% of the time on the exact > > same files...). Also, the branch variable shown above is not the only > > variable it crashes on - it seems to pick a variable at random from one of > > the three trees each time it crashes. My only guess is that there's some > > odd memory leak, but since I only have two new statements in the entire > > routine (one per file opened - two of the trees are in one file, another > > is in the other file), I'm absolutely sure I delete things properly. Any > > information is appreciated. > > > > David Relyea > > > > >
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:58 MET