Reading ROOT 4 files with ROOT 5

Hi,

if I try to read with ROOT 5.10.00c my own classes from a ROOT file that was written with ROOT 4.04.02 I get a number of errors:

Error in : object of class BbrUuidK read too few bytes: 12 instead of 42
Error in : object of class KanObj read too few bytes: 16 instead of 34
Error in : object of class BbrUuidK read too few bytes: 12 instead of 42
Error in : object of class KanObj read too few bytes: 16 instead of 34
Error in : object of class KanObj read too few bytes: 16 instead of 34

though I did not touch the schema of these classes. Is there anything I can do to fix that?

Thanks,
Matthias

This should of course not happen :slight_smile:
Could you send more information about your problem (or a complete example to reproduce it)?
Are you using the new or old I/O, what is the content of your classes?
What is the result of

gROOT->GetClass("BbrUuidK")->GetStreamerInfo()->ls(); gROOT->GetClass("BbrUuidK")->GetStreamerInfos()->ls();

Cheers,
Philippe[/quote]

Hi Philippe,

BbrUuidK is quite simple. This is its header file:

#include "TObject.h"
#include "TString.h"
#include "BbrUUID/Guid.hh"

class BbrUuidK : public TObject {
public:
  BbrUuidK();
  BbrUuidK(const BbrUUID::Guid& id);
  virtual ~BbrUuidK( );

  const BbrUUID::Guid& getUuid() const;
  Bool_t   rolloverExists() { return _successor > 0; }
  UShort_t successor() { return _successor; }
  TString  thisFileFullExtension();
  TString  thisFileExtension();
  TString  rolloverExtension();

  void setUuid(const BbrUUID::Guid& id);
  void setSuccessor(const UShort_t& next) { _successor = next; return; }
  void setExtension(const TString& ext) { _extension = ext; return; }

  const BbrUUID::Guid& setUuid();
  virtual void Print(Option_t* option="") const;

protected:
private:
  UChar_t _uuid[16];            //  The Persistent Data
  mutable BbrUUID::Guid* _guid; //! The Transient Guid;
  UShort_t _successor;          //  The continuation File Index
  TString  _extension;          //  Extension of continuation file

  ClassDef(BbrUuidK,1)          //  A Unique UID for Kanga Files

};

And this is the output of the GetStreamerInfo()-l>s():

root [1] gROOT->GetClass("BbrUuidK")->GetStreamerInfo()->ls()

StreamerInfo for class: BbrUuidK, version=1
  TObject        BASE            offset=  0 type=66 Basic ROOT object
  UChar_t        _uuid[16]       offset= 12 type=31 The Persistent Data
  UShort_t       _successor      offset= 32 type=12 The continuation File Index
  TString        _extension      offset= 36 type=65 Extension of continuation file
   i= 0, TObject         type= 66, offset=  0, len=1, method=0
   i= 1, _uuid           type= 31, offset= 12, len=16, method=0
   i= 2, _successor      type= 12, offset= 32, len=1, method=0
   i= 3, _extension      type= 65, offset= 36, len=1, method=0
root [2] gROOT->GetClass("BbrUuidK")->GetStreamerInfos()->ls();

StreamerInfo for class: BbrUuidK, version=1
  TObject        BASE            offset=  0 type=66 Basic ROOT object
  UChar_t        _uuid[16]       offset= 12 type=31 The Persistent Data
  UShort_t       _successor      offset= 32 type=12 The continuation File Index
  TString        _extension      offset= 36 type=65 Extension of continuation file
   i= 0, TObject         type= 66, offset=  0, len=1, method=0
   i= 1, _uuid           type= 31, offset= 12, len=16, method=0
   i= 2, _successor      type= 12, offset= 32, len=1, method=0
   i= 3, _extension      type= 65, offset= 36, len=1, method=0
root [3]

And finaly the line in the LinkDef file is

#pragma link off all globals;
#pragma link off all classes;
#pragma link off all functions;

#pragma link C++ namespace BbrUUID;

#pragma link C++ class Kan;
#pragma link C++ class BbrUuidK;
...

Thanks,
Matthias

[quote=“pcanal”]This should of course not happen :slight_smile:
Could you send more information about your problem (or a complete example to reproduce it)?
Are you using the new or old I/O, what is the content of your classes?
What is the result of

gROOT->GetClass("BbrUuidK")->GetStreamerInfo()->ls(); gROOT->GetClass("BbrUuidK")->GetStreamerInfos()->ls();

Cheers,
Philippe[/quote][/quote]

Can you try with:

#pragma link C++ class Kan+; #pragma link C++ class BbrUuidK+; If this does not work, please send me enough code to reproduce your failure.

Thanks,
Philippe

Philippe,

It is likely that Matthias did not specify the “+” in the pragma statement when he wrote the file. As a result the auto schema evolution is not activated.

Rene

Hi everybody,

if I use #pragma link C++ class BbrUuidK+; the error message concerning BbrUuidK disappears. For some other classes the message is still there and the application crashes somewhat later. So I guess things may work if I add a “+” for all classes which show up in the error messages. I"ll have to recompile a bunch of packages before I can test that.

Rene is right, there was no “+” when the file was written. Does that mean that my test will fail and we have a basic problem reading the BaBar event data with ROOT 5 based releases?

Matthias

[quote=“brun”]Philippe,

It is likely that Matthias did not specify the “+” in the pragma statement when he wrote the file. As a result the auto schema evolution is not activated.

Rene[/quote]

Rene is right, there was no "+" when the file was written. Does that mean that my test will fail and we have a basic problem reading the BaBar event data with ROOT 5 based releases? In particular it means that there is no automatic schema evolution support. So if anything changed in any of the classes, the developer need to code and modify by hand the streamer.

Cheers,
Philippe.

Hi Philippe,

ok, but that’s not a real show stopper.

I’m currently compiling. Probably tomorrow I’ll know if the "+"s fix my problem.

Matthias

[quote=“pcanal”]Rene is right, there was no "+" when the file was written. Does that mean that my test will fail and we have a basic problem reading the BaBar event data with ROOT 5 based releases? In particular it means that there is no automatic schema evolution support. So if anything changed in any of the classes, the developer need to code and modify by hand the streamer.

Cheers,
Philippe.[/quote]

Hi Philippe,

what I found out in my tests is that if I add a “+” for BbrUuidK and then read an “old” file, the error message concerning BbrUuidK has gone, but reading back a BbrUuidK does not work. It looks like the data is read only partially. This lets the application crash soon.

If I do not add "+"s I get all the error messages, but the objects which are read back seem to be ok. The application log files which I get using ROOT 4 and which I get with ROOT 5 differ by the CheckByteCount error messages only. I’ll try to run something that produces “physics” output which I can compare.

Is it possible that the input works properly and the error message should be suppressed?

Matthias

Hi Philippe,

I run a real job with physics output on some of our “old” ROOT files, and I got identical results for ROOT 4 and ROOT 5. But I get tons of “CheckByteCount” error messages. Is it ok to ignore the messages, and would it be a good idea to switch them off in the ROOT sources?

Thanks,
Matthias

[quote=“matthiasSteinke”]Hi Philippe,

what I found out in my tests is that if I add a “+” for BbrUuidK and then read an “old” file, the error message concerning BbrUuidK has gone, but reading back a BbrUuidK does not work. It looks like the data is read only partially. This lets the application crash soon.

If I do not add "+"s I get all the error messages, but the objects which are read back seem to be ok. The application log files which I get using ROOT 4 and which I get with ROOT 5 differ by the CheckByteCount error messages only. I’ll try to run something that produces “physics” output which I can compare.

Is it possible that the input works properly and the error message should be suppressed?

Matthias[/quote]

Matthias,

You can remove the warning message in two ways
1- Set gErrorIgnoreLevel = 1 (in TError.h) (default is 0)
2-Set the error level in your system.rootrc or .rootrc file
Root.ErrorIgnoreLevel : 1

The fact that you did not specify the “+” when writing your classes will become a growing problem for you. The “+” selects the automatic schema evolution. We cannot put this option by default for back compatibility reasons. If you write new files, ALWAYS specify the “+”

Rene

Hi Rene,

thanks for the hints. I looks like we have to think a bit how to handle backward compatibility for our existing event data and adding "+"s in BaBar.

Greetings,
Matthias

[quote=“brun”]Matthias,

You can remove the warning message in two ways
1- Set gErrorIgnoreLevel = 1 (in TError.h) (default is 0)
2-Set the error level in your system.rootrc or .rootrc file
Root.ErrorIgnoreLevel : 1

The fact that you did not specify the “+” when writing your classes will become a growing problem for you. The “+” selects the automatic schema evolution. We cannot put this option by default for back compatibility reasons. If you write new files, ALWAYS specify the “+”

Rene[/quote]