I am using the boost 1.33.1 distribution, and the
xml_iarchive and xml_oachive to serialize a rather deep and complex data
structure to xml. I am using make_nvp directly in all cases (not the
macro).
I am sometimes getting the following assert (line 71 in
extended_type_info.cpp) when I load previously serialized data:
assert( lookup(eti) == m_self->m_map.end() );
It seems obvious that what is happening is that somehow I am
calling self_register more than once for a specific class. Tracing through
the code however I am puzzled exactly how this could happen, since the
registration should only happen once when the libraries are loaded. This
never happens on save by the way, only on load. It also never happens if
I do the save, followed by a load immediately. It only happens if I do
the save, shut down the application, then load the data. I have verified
that the loaded data is a bit by bit equivalent in both cases.
The best that I can come up with is that I am loading the
serialization library as a side effect of calling LoadLibrary at runtime.
So I am linking in the serialization library after everything else has been
loaded and is running. But again, none of the libraries are ever
unloaded, and the load sequence should always be the same.
The actual situation is that I have a library … call
it Library A, which is linked to libraries B, and C. The library A is
being linked using the LoadLibrary call, each of libraries B are C are linked
to the boost serialization library.
In each of libraries B, and C, I have used the macro:
BOOST_CLASS_EXPORT_GUID(
class, "ClassNameText"
)
To define all of my classes I am serializing, including all
classes that I am serializing using shared_ptr’s. I was thinking
originally that the problems were all shared_ptr’s of classes that are
derived from enable_shared_from_this<T>, but I am no longer confident
that has anything to do with it.
In fact, truth be told, I have no idea if any of the above
has anything to do with the problem. When I commented out the assertion,
everything seems to work just fine, except now I am getting a stack overflow on
very complex hierarchies in the spirit parser (again, load only), but the
simpler ones seem to work repeatedly without any problems.
I have no doubt that the assertion was added there for a
reason, so I hate to comment it out without finding out what else I might have
broken…
Edward Reusser
Principal Engineer
Actel Corporation
(650) 318-4972