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 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
tree.GetUserInfo(0->Add(myobject);
I copied a shared lib that should contain all necessary symbols to ep1.rub.de/~matthias/libKanga_root.so
The library was created on RH7.2, but it should work on more uptodate versions
of Linux, too. Maybe this helps.
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.
No progress with your latest file. Running on a SLC3 system, I see undefined the following shared libs required to load your library libtcl8.0.so
liboo.so.8 liboocx.so
liboocx_pkgid_8.0.0.so
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
gDebug=2;
and send me the complete output.
I have to fight other problem today; please give me one or two days to produce some debug
output.
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
shared lib).
Could you make a simple test with basic root.exe
root > TFile f(“myfile.root”)
and see if you still have the problem.
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 ep1.rub.de/~matthias/updateError.log and ep1.rub.de/~matthias/noUpdated.log
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 ep1.rub.de/~matthias/unzipError.log
I copied the output for some good events and for some bad events to the log file.