we use AutoSave() for checkpointing of the output of the BaBar production applications. If
I try to read the output of a crashed application, ROOT successfully recovers everything,
and the reading application works fine. But if I try to open the damaged file in UPDATE mode
and close it (after ROOT again recovered everything), I get an error in some cases if I try
to read the recovered file. The error message is
R__unzip: error in header
Is this a known effect, and is there something I can do to avoid the error? Or did I run into
a new problem?
I tried ROOT 4.01.02 and 4.00.08.
Is your file close to the 2Gbytes size?
Could you send me the shortest possible file
(or tell me where I can take it) before updating the file.
the file has just 5MByte. I copied the un-recovered file to
ep1.rub.de/~matthias/AllEven … .root-orig
You will find some unknown classes in there; I hope that’s not a problem.
I looked at your file. As you say it is recovered in “update” mode.
However, I cannot test your problem because I cannot read
your class babarTree.
Note that since version 4.00/08 you do not need to derive a class from TTRee
to store additional parameters. We added the possibility to add
as many objects as you like to the Tree header via
I copied a shared lib that should contain all necessary symbols to
The library was created on RH7.2, but it should work on more uptodate versions
of Linux, too. Maybe this helps.
I cannot use your library on my RH7.3 system. Which compiler did you use?
yeah, the library was compiled with gcc2.95.3, and that probably is not your current
favorite. I copied a second library that was compiled with gcc3.2.3 on RHEL3 to
ep1.rub.de/~matthias/libKanga_root_gcc323.so. I hope that works.
I cannot find the shared lib at this URL.
the stop “.” became part of the link in my last posting. Please try
No progress with your latest file. Running on a SLC3 system, I see undefined the following shared libs required to load your library
and many others
I doubt that it’s a good idea to copy all shared libs we have in BaBar to my web area, and you copy them over to your pc to run into the next problem. Does somebody of the ROOT people have a BaBar account at SLAC? Too bad that Pete Elmer is on vacation. Can I run something and send you the output?
You should try to localize as much as possible the event or event(s)
for which you see a problem. If you can,
then before calling GetEntry for this event, set
and send me the complete output.
I have to fight other problem today; please give me one or two days to produce some debug
The r_unzip error comes up when the file gets openend, not later at a GetEntry(). Therefore
I think debug output for Open() (or the TFile ctor) would be usefull.
Interesting! I can open the updated file without problems (but I do not have your
Could you make a simple test with basic root.exe
root > TFile f(“myfile.root”)
and see if you still have the problem.
Take your time. I am very busy this week too.
I tried a simple ‘TFile f("<damaged_file>")’ in plain ROOT w/o any BaBar shared libs loaded, and that works.
Then I added a ‘gDebug=2’ to our ‘KanFileUtil’ , that mainly opens a ROOT file and calls
Print() for the trees it finds. This gives R__unzip errors. For the original, not UPDATEd file this works w/o errors. I copied the log files with the gDebug output to
I don’t know if a second problem we have has the same origin, but it least it results in
R__unzip error messages, too. Here the errors come up after reading 55000 events
successfully, and the ROOT file was not recovered by an UPDATE, and the application that wrote the file did not crash. You’ll find the gDebug=2 output in
I copied the output for some good events and for some bad events to the log file.