Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92

Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-10-22 21:38:45

Robert,

Thanks for your response.

> When I look at the code I can explain what I had in mind.
> 
> The ktmap ([export]key - type)map should have an entry for each
> instance of an exported type. These entries are static variables.
> So, when one of these static items are destroyed, its ktmap entry
> should be erased.  The assertion is meant to trap a the case
> where the key isn't found in the map.  Such a circumstance would
> indicate the map has become out of sync with the variable involved.
> In the absense of multi-threading should never happen.
> 
> The code subsequent to the assertion presumes that at least
> one entry exists in the ktmap (do ...) so the assertion was
> there to detected an error in this presumption. So trapping on
> this condition inidicates that there must be an error somewhere
> else.   I would expect that this is somewhere in the library
> rather than in the user's program.
> 
> I could implement your suggestion, but I would much rather
> get to the bottom of it.

Sure, understand. The problem is that in release mode my application just
hangs indefinitely after main() exited and there is no way of terminating it
short of kill -9. Not something I can ask my users to do all the time.

> dlopen(RTLD_GLOBAL|RTLD_LAZY) suggests to me that
> dlls are being loaded/unloaded outside of your control.  The
> serialization library presumes that dlls are not loaded/unloaded
> but more than one thread at at time.  Its concievable that this might
> be an issue.

The shared libraries are loaded/unloaded in a fully controlled way at well
defined points. Additionally, no multithreading is involved at the point of
loading the libraries. Unloading happens after main() exited, so
multithreading isn't an issue there either. The only reason why I wrote
about dlopen(RTLD_GLOBAL|RTLD_LAZY) was that it just didn't work at all when
I was using other flags (especially RTDL_LOCAL and RTDL_DEEPBIND mess things
up - which is worth mentioning in the docs as it took me a couple of days to
figure this out).

A bit more detail about how I set things up:

I'm serializing polymorphic objects through a shared_ptr to the base class.
The object definitions are distributed over several shared libraries, all of
them loaded using dlopen (on Windows 32/64Bit everything is fine, BTW). Each
object has a corresponding BOOST_CLASS_EXPORT() placed in one of the cpp
files each (not the headers) of the corresponding shared library. Boost
serialization is linked dynamically (to ensure to have one typeinfo
registry) as well, but the corresponding shared (boost) library is linked
with the application, so it is loaded at application startup.

Regards Hartmut

> 
> Robert Ramey
> 
> 
> 
> Hartmut Kaiser wrote:
> > Robert,
> >
> > Would it be possible to get an answer to my initial questions,
> please?
> >
> > Thanks!
> > Regards Hartmut
> >
> >
> >> Anything I can do about this?
> >> What does this assertion mean?
> >>
> >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for
> >> polymorphic objects loaded from different shared libraries, shared
> >> libraries are loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY).
> >>
> >> Assertion (extended_type_info.cpp:92) occurs during program
> >> termination (after main returned), during dlclose().
> >>
> >> If anything else isn't possible, would it be appropriate to change
> >> the related code (before the release!) from:
> >>
> >>         assert(start != end);
> >>
> >>         // remove entry in map which corresponds to this type
> >>         do{
> >>             if(this == *start)
> >>                 x.erase(start++);
> >>             else
> >>     ++start;
> >>         }while(start != end);
> >>
> >> To:
> >>
> >>         assert(start != end);
> >>
> >>         // remove entry in map which corresponds to this type
> >>         while(start != end) {
> >>             if(this == *start)
> >>                 x.erase(start++);
> >>             else
> >>     ++start;
> >>         }
> >>
> >> Which wouldn't remove the problem, but at least avoids hanging the
> >> program if assertions are off...
> >>
> >> Regards Hartmut
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost