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