Re: [Boost-users] [Serialization] unexpected assert registering classes

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
[phone]

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://lists.boost.org/mailman/listinfo.cgi/boost-users