[serialization] Will a void_caster fix be available for 1.43?
I try again: is there any chance for a fix to this problem to make it into 1.43.0? I get an access violation after explicitly unloading a DLL that contains serialization code for a series of classes. I believe there might be a bug in void_caster::recursive_unregister(): that function member is called in the destructors of the void caster template classes. It searches the set inside void_caster_registry singleton for all the entries that are descendants of the current one (i.e., the void_caster being destroyed) and performs the following operations: - 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 repeats the traversal for whatever executable-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 100% sure about the reason or whether a simple unregistration is enough. Thank you, Bogdan
participants (1)
-
Bogdan