Re: [boost] [1.37.0][serialization] Assertionfailed at libs/serialization/src/extended_type_info.cpp:92

Subject: Re: [boost] [1.37.0][serialization] Assertionfailed at libs/serialization/src/extended_type_info.cpp:92
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-10-23 09:26:54

Robert,

Thanks for your response.

> > 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.
> 
> In a pinch, you can tweak your copy of the library while this gets
> sorted 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.
> 
> This looks perfect to me.
> 
> A little bit of time trapping
> on key_register and key_unregister might explain what's up.
> 
> There should be one key_register and a matching key_unregister
> for each exported type. Since this is very hard to reproduce,
> could I ask you to spend a little time investigating why
> this seems not to be true in this case?  I would hope
> that trapping on these two functions and watching what
> the arguments are might shed light on the mystery.

Ok, here is what I got. Everything suddenly starts to work as soon as there
is at least one BOOST_CLASS_EXPORT() inside a shared library which is loaded
at application startup (not loaded with dlopen()). But please don't ask me
why, it's just good to know. Perhaps we're dealing with some idiosyncrasies
of the dlopen() library in combination with gcc symbol visibility rules.

Problem solved, thanks again!
Regards Hartmut