Root 4 cannot read back Root 3 STL maps?

ROOT
1

Hi,

In Phenix, we’re getting some trouble to read back with Root 4.00/08 some objects on our dsts (produced with Root 3.05/07), namely objects that contain STL maps.

I attach a very simple example to reproduce the problem. The Makefile there is for Linux. It produces 2 executables : writeMap and readMap. Under the same Root version (being 3 or 4), expected output is :

./writeMap
titi -> 2
toto -> 1
./readMap
titi -> 2
toto -> 1

The faulty output file (testmap.root) is included in the tar file.

When writeMap is executed under Root3.05/07 and readMap under Root4.00/08, here’s what I get :

Warning in TStreamerInfo::BuildCheck:
The StreamerInfo of class Map read from file testmap.root
has the same version (=1) as the active class but a different checksum.
You should update the version to ClassDef(Map,2).
Do not try to write objects with the current class definition,
the files will not be readable.

Warning in TStreamerInfo::BuildOld: Cannot convert Map::fMap from type:mapstd::string,int to type:map<string,int,less,allocator<pair<const string,int> > >, skip element
Error in TStreamerInfo::ReadBuffer: The element Map::fMap type 400 (mapstd::string,int) is not supported yet

Error in TBuffer::CheckByteCount: object of class Map read too few bytes: 12 instead of 40

Any hints how to solve this ?

Thanks,

PS:

Root 3.05/07 used is installed on a RH8.0 machine 2.4.20-19.8smp
Root 4.00/08 used is installed on a SL3.01 machine 2.4.21-15.ELsmp
Map2.tar.gz (1.73 KB)

2

HI,

I built readMap with root 4.00/08 gcc 3.3.1, with root 4.01/01 with icc 8 and gcc 3.3.1 and was unable in all 3 cases to reproduce your problem!

Make sure that you have regenerated the dictionary between the 2 versions.

It does not sound right that TStreamerInfo would see map<string,int,less,allocator<pair<const string,int> > >

Which version of gcc are you using?

You should be getting:

[code]root [0] .L Map.C+
root [1] gROOT->GetClass(“Map”)->GetStreamerInfo()->ls()

StreamerInfo for class: Map, version=1
TObject BASE offset= 0 type=66 Basic ROOT object
mapstd::string,int fMap offset= 12 type=300 ,stl=4, ctype=61,
i= 0, TObject type= 66, offset= 0, len=1, method=0
i= 1, fMap type=300, offset= 12, len=1, method=0
[/code]

Cheers,
Philippe

3

Hi Philippe,

Indeed, using .L Map.C++ I get the same output as you get :

root [2] gROOT->GetClass(“Map”)->GetStreamerInfo()->ls()

StreamerInfo for class: Map, version=1
TObject BASE offset= 0 type=66 Basic ROOT object
map<string,int> fMap offset= 12 type=300 ,stl=4, ctype=61,
i= 0, TObject type= 66, offset= 0, len=1, method=0
i= 1, fMap type=300, offset= 12, len=1, method=0

But still the executable readMap gives the same error. And yes, the dictionary has been rebuilt.

The compiler on that SL3.01 machine is : gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-34)

I also tried on my laptop (FC1, gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)), and got the same bad result with readMap.

Regards,

4

Hi,

Can you send me a tar file with the built result from your laptop (including dictionary and object files)?
Can you try with a ROOT version build from the head of the CVS repository?

Cheers,
Philippe

5

Hi,

Here’s the built thing.

I’ll try with the cvs head and let you know (that might take a little bit more time)

Regards,
Map2built.tar.gz (70.2 KB)

6

With a local build of 4.01/01 from cvs head (from a few minutes ago) it works fine :
./readMap [01 Sep 19:46]
titi -> 2
toto -> 1

Does it mean we have to forget about Root 4.00/08 to read back our dsts ?

7

Hi,

I just download the source again from ftp://root.cern.ch/root/root_v4.00.08b.source.tar.gz and rebuild on RedHat 7.3 with gcc 3.3.1 and I was able to reproduce your problem.

I am looking for a work-around.

Cheers,
Philippe.

8

Hi,

So far the easiest work-around that I can find is for you to download the latest cint/src/typedef.c and use it to compile ROOT 4.00/08.

Cheers,
Philippe.

9

I’ve justed tested this on my FC1 laptop and it indeed works fine.

I’l l test it later on on the SL3 machines.

Thanks for your help,

Regards,