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