Re: [Boost-users] Polymorphic serialization with polymorphic archives problems... [part 2]

Subject: Re: [Boost-users] Polymorphic serialization with polymorphic archives problems... [part 2]
From: Jan Boehme (jan.boehme_at_[hidden])
Date: 2010-11-03 13:02:28

On 03/21/2010 10:28 PM, Bogdan wrote:
> First I would like to confirm I tested Robert Ramey's fix (@60273) for
> multiple registrations and it looks good in my runs. Thank you Robert!
> 
> On the other hand, I am under the impression there is a bug in
> void_caster::recursive_unregister(), although I am not 100% certain about
> the reason: that function member is called in the destructors of the void
> caster template classes and makes use of the void_caster_registry singleton
> (more specifically the type_set). I believe it searches the set for all the
> void caster entries that are descendants of the current one (i.e., the one
> being destroyed) and performs the following ops:
> - delete the shortcuts. 
> - remove the corresponding entries from the set.
> 
> However, void_caster::recursive_unregister() DOESN'T REMOVE FROM THE
> REGISTRAR the entry corresponding to the current void_caster(). This creates
> the problem below:
> 
> consider a scenario where a dll containing some serialization functionality
> is loaded explicitly at runtime (i.e., using LoadLibrary() on Windows or
> dlopen on Unix). There are no parent-child relationships among the
> serialized classes registered by that DLL: all serialized classes are
> derived from one abstract base. While unloading the library, its void_caster
> singletons are destroyed but there are no shortcuts to remove from the
> global registrar since there are no parent-child relationships. All entries
> corresponding to those are still in the global registrar and POINT TO THE
> void_caster  SINGLETONS ALREADY DESTROYED AND DISCARDED.
> 
> When the main process exits, the registrar traversal repeats for whatever
> process-bound void_caster singletons are about to be destroyed. During these
> subsequent traversals, void_caster::recursive_unregister() visits the
> entries left after the previous explicit dll download and tries to identify
> the parent-child relationship. In doing so, it accesses the dangling vc
> pointers generating access violations:
> 
> void_cast.cpp(Line 286):        const void_caster * vc = *it;
> void_cast.cpp(Line 287):        if(vc->m_parent == this){
> //<--------------------- here is the access violation
> 
> I can reproduce the crash systematically, but I am not sure about the reason
> or whether a simple unregistration is enough.
> 
> I believe this is (again) a question for Robert, but I thank for any
> feedback I might get.
> 
> Bogdan

Hi,

did you receive any help yet? We have the same problem here but are
unable to reproduce the behavior in a small test which we would like to
provide in a bug report though.
Can you provide a straightforward sample to reproduce the problem?

Jan