From: Robert Ramey (ramey_at_[hidden])
Date: 2006-11-13 11:24:15
Having serialization code in DLLS has raised some stick issues. The basic
problem is the existence of a global table of information about types being
serialized. Among other thngs, this global type table contains the export
string name (GUID) that is shared among programs to identify the type. This
table also points to functions via a virtual function mechnamism to
implementations required by serialization.
Entries are added to this table when code is loaded and deleted when code is
unloaded.
in version 1.33 I included the indicated assert - as it seemed to me that
this must be unique. I was concerned that multiple entries in the table
might point to different function implementations - as
indeed they will. So I included this assertion.
This started to create problems as you have found. Also I've now come to
thnk that the
having multiple entries for the same type is harmless - and difficult to
avoid in the
presence of dynamically loaded/unloaded DLLS. So in 1.34 - I commmented out
the assertion.
In addition, I've augmented the code to make sure that the correct entry in
the table is
deleted when the corresponding DLL is unloaded. So I believe that starting
in 1.34 this
problem will be resolved. I really don't know for sure because its very
hard to come up
with a good test for this.
So, I think this problem is addressed. But in the face of dynamically loaded
DLLs - which are not
all guarenteed to be in sync ( some could have older versions of code), I
think that the best
policy would be to be sure that serialzation code for a particular type
should be found in one
and only one place. Also, doing this will result in smaller DLLS and
applications. Doing this
requires that one explicitly orgranize his code so to achieve this. This
means avoiding instantiation
of serialization code in applications and by explicitly instantiation such
code in the DLLS. The
closest guide I have for doing this is demo_pimpl which shows how to do
this.
Robert Ramey
"Reusser, Edward" <Edward.Reusser_at_[hidden]> wrote in message
news:5E916BAE1732F344BAFD713DF2373479016EA054_at_SV-MSG-01.amer.actel.com...
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
The information contained in or attached to this email may be subject to the
Export Administration Regulations (EAR), administered by the U.S. Department
of Commerce, or the International Traffic in Arms Regulations (ITAR),
administered by the U.S. Department of State, and may require an export
license from the Commerce or State Department prior to its export. An export
can include a release or disclosure to a foreign national inside or outside
the United States. Include this notice with any reproduced portion of this
information.
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://listarchives.boost.org/mailman/listinfo.cgi/boost-users