Hopefully later today.

Cheers, Fons.

Congratulations...
We normally stick to production versions of root for our production. So it would be great if we could get a bug-fix release 5.12/00f.

Thanks for the prompt action and information about the status. Are there any further news?

I also made the files which produced the crash available at the location mentioned before.

Just replace all the c.Add() in the macro by:
c.Add("20060724_00096230_Y_HB89-1553+11-W0.40+000_E.root");
c.Add("20060724_00096231_Y_HB89-1553+11-W0.40+000_E.root");

Yes, of course. In
http://www.astro.uni-wuerzburg.de/~...
you can download these files and a macro I used to reproduce the error.

However I'm not sure if reproducing this problem is so easy. I tries to run the macro with our shared object (with the root dictionary) loaded and it crashed immediatly. (If necessary I can give you advise how to build the necessary dictionary)

I get the following output from the macro:
Processing test.C...
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
110000
120000
130000
140000
R__unzip: error in inflate (zlib)
Error in <TBasket::ReadBasketBuffers>: fNbytes = 16343, fKeylen = 93, fObjlen =30064, noutot = 0, nout=0, nin=16250, nbuf=30064
Warning in <TBasket::ReadBasketBuffers>: basket:MSignalCam.fPixels.fPhot has fNevBuf=13 but fEntryOffset=0, pos=125099594, len=30157, fNbytes=16343, fObjlen=30064, trying to repair
Error in <TBranchElement::GetBasket>: File: /magic/data/callisto/0009/00099057/20060827_00099063_Y_PSRB1951+32_E.root at byte:124087943, branch:MPedPhotFundamental.MParContainer, entry:22779, badread=1
150000
160000
R__unzip: error in inflate (zlib)
Error in <TBasket::ReadBasketBuffers>: fNbytes = 16179, fKeylen = 93, fObjlen =30064, noutot = 0, nout=0, nin=16086, nbuf=30064
Warning in <TBasket::ReadBasketBuffers>: basket:MSignalCam.fPixels.fPhot has fNevBuf=13 but fEntryOffset=0, pos=190115882, len=30157, fNbytes=16179, fObjlen=30064, trying to repair
Error in <TBranchElement::GetBasket>: File: /magic/data/callisto/0009/00099057/20060827_00099063_Y_PSRB1951+32_E.root at byte:196076208, branch:MPedPhotFundamental.fSectors.fUniqueID, entry:37211, badread=1
root [1]

We are still checking if we can find a single file reproducing the error, but so far without luck.

I get the following error messages reading some of our files (more details see below)
R__unzip: error in inflate (zlib)
Error in <TBasket::ReadBasketBuffer>: fNbytes=16343, fKeylen=93, fObjlen=30064, noutot=0, nout=0, nin=16250, nbuf=30064
Warning in <TBasket::ReadBasketBuffer>: basket:MSignalCam.fPixels.fPhot has fNevBuf=13 but fEntryOffset=0, pos=125099594, len=30157, fNbytes=16343, fObjlen=30064, trying to repair
/Error in <TBranchElement::GetBasket>: File: xxx.root at byte:124087943, branch:MPedPhotFundamental.MParContainer, entry:22779, badread=1

This error can easily be reproduced by:
TChain c("MyTree");
c.Add("file1.root");
c.Add("file2.root");
...
c.Add("xxx.root");
Int_t n=c.GetEntries();
for (int i=0; i<n; i++)
c.GetEntry(i);

Due to the error "trying to repair" my first idea was that the file xxx.root is corrupted somehow. But reading only this file (without others) in a TChain or changing the order (reading xxx.root first) makes the error disaapear. So I don't think that the file itself can be corrupt (btw: producing the files again reproduces the error, so it is nothing which has to do with the filesystem).

My next idea was, that it is a bug in a root version which might be fixed already, but neither using 5.12/00b, 5.12/00e or 5.13/04 changed nothing. (We have never experienced the problem with older root versions, namely 4.04/02g, but I cannot check it anymore because the program producing the files now needs some features of root 5.*)

I also checked if a streamer of one of our classes is somehow producing correupted files or corrupted input, but this is excluded, because all written objects have a streamer created by root (not by me).

Because the error can disaappear if the order of the files in the TChain is changed, and all streamers used to read the file I guess it is a problem in root I/O reading these files.

Some additional information:
MPedPhotCam.fPixels is a TClonesArray
MPedPhotCam.fPixels.fPhot is a Float_t
MPedPhotFundamental.MParContainer is a base-class derived from TObject which is almost identical to TNamed but hass classVersion=0 to suppress streaming of its data members.

Our system is currently running over TBs of data to check whether we can reproduce this error also with a single file (without the TChain), but I doubt.