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

Subject: [Boost-users] Polymorphic serialization with polymorphic archives problems... [part 2]
From: Bogdan (bogdan.indy_at_[hidden])
Date: 2010-03-21 17:28:47

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