Re: [Boost-users] [serialization]Runtime Exception While Loading Old Serialized XML Files w/ 1.38

Subject: Re: [Boost-users] [serialization]Runtime Exception While Loading Old Serialized XML Files w/ 1.38
From: Yaser Zhian (yaserzt_at_[hidden])
Date: 2009-01-28 11:57:36

Robert Ramey wrote:
> First of all, any failure to read any archive created under a previous
> version of the library is a bug.  Thanks for pointing this out.
> 

Thanks for your interest.
Since my last post, I have verified that the problem was indeed fixable
(or rather, circumventable) by adding an "item_version" tag where it was
missing. I'll explain more below.

> This is likely fixable, but we would need a little more information.
> 

I'm sorry if my first description was vague. I'll try to be more
precise, but I'm afraid I'm quite unfamiliar with the boostian terminology!

> a) I'm not sure what version 4 and version 5 refers to - expand upon this.

OK. At the beginning of a serialized XML file, after the "<?xml..." tag
and the "<!DOCTYPE...", there's a "boost_serialization" tag with two
attributes; "signature" which is "serialization::archive" and "version".
I was referring to this version, which used to be "4" when my files were
serialized, and now with the updated libs from the trunk, it is "5".

> b) I'm not sure what type the "item_version" refers to. Is it the list type 
> or (more likely) the type which is being pointed to.
> c) what type is being pointed to?

Well, I can't say I'm positive either! Basically, the relevant part of
my type structure looks like this:

//BEGIN_CODE
class Component {
        ...
};

class CompA : Component {...}
class CompB : Component {...}
class CompC : Component {...}

class Object {
        ...
        
        std::map<std::string, Component *> name_comp_table;
        std::vector<Component *> interesting_comps;
};
//END_CODE

Basically, I serialize instances of Object. The interesting_comps member
holds pointers to Components that already exist in name_comp_table. The
CompX classes are what actually stored in Objects using pointers to
their polymorphic base class Component.
It is in the serialization of the interesting_comps member of the Object
class that this possible bug happens. Since all the objects pointed to
by the elements of the interesting_comps vector are already serialized,
the serialization system (rightfully) just stores an
"object_id_reference" in the file, like this:

//BEGIN_DATA
...
<interesting_comps class_id="12" tracking_level="0" version="0">
  <count>10</count>
  <item class_id_reference="13" object_id_reference="_13"></item>
  <item class_id_reference="15" object_id_reference="_14"></item>
  <item class_id_reference="16" object_id_reference="_15"></item>
  <item class_id_reference="17" object_id_reference="_16"></item>
  <item class_id_reference="17" object_id_reference="_17"></item>
  <item class_id_reference="17" object_id_reference="_18"></item>
  <item class_id_reference="17" object_id_reference="_19"></item>
  <item class_id_reference="19" object_id_reference="_22"></item>
  <item class_id_reference="20" object_id_reference="_23"></item>
  <item class_id_reference="21" object_id_reference="_25"></item>
</interesting_comps>
...
//END_DATA

I think the above lacks an "item_version" tag after the "count" tag.
Like so:

//BEGIN_DATA
...
  <count>10</count>
  <item_version>0</item_version>
  <item class_id_reference="13" object_id_reference="_13"></item>
...
//END_DATA

In fact, I wrote a script that went through all my serialized XML files,
checked whether this "item_version" tag existed or not, and added it if
it didn't.
This solved my problem completely and now the files load as they did before.
Also, I found out that the example I gave you above was the only place
that this wrong behavior happened (I have several hundred of these
Objects per XML file on average, and this happened in all of them and
nowhere else.) I also use serialization for several other STL
containers, including vectors and maps, but none of them contains
pointers to previously serialized data and none of them behaves
erratically.

I can post real header files and real serialized data if you want, but I
doubt they'll be useful to anyone due to excessive noise. I may be able
to reproduce the problem using simpler data structures if really needed
(however, since my immediate problem is solved and due to a tight
schedule in this project, that may take a few days.)

> d) can we assume no changes in the serialization traits?
> 

I guess so. During these tests, I did not touch any of my own code. I
only replaced older Boost header and library files with freshly
checked-out and built ones.

> Robert Ramey
> 

Again thanks for your time and interest.
-yzt