I’m loading VTK as a visualization plugin from within an MFC application, and when I go to close my application and the plugin is unloaded with FreeLibrary, vtkCommonInformationKeyManager will crash. Immediately before the FreeLibrary call everything is fine, but when vtkCommonInformationKeyManager::ClassFinalize is called by the FreeLibrary call, all keys which weren’t created by vtkCommonCore are corrupt and crash with a read access violation exception when deleted. The key’s Name and Location parameter strings are still correctly set, but the __vfptr table is unreadable.
I realize that vtkCommonDataModel and vtkCommonExcecutionModel (among others) create their own information keys as static variables which are registered with the key manager which will properly delete them when VTK is closed. I’m wondering if these dlls are being unloaded first, and any memory they have allocated is being locked by Windows before the key manager tries to delete the keys? I have verified the destructors for the invalid keys are not being called.
If I manually override vtkCommonInformationKeyManagerCount so the first dll loaded will delete all referenced keys, they will unload cleanly, but if any of those static variables are referenced by a plugin which has not been disposed yet, I know it will be using a dangling pointer and would prefer not to leave loose ends. This test exposes that the same sort of issue also happens with vtkObjectFactory with the vtkObjectFactoryRegistryCleanupCounter, with similar results.
All of the references to VTK dlls are built into a static lib which is referenced by the plugin dll loaded by the exe. The static lib’s precompiled header includes a list of most of the vtk header files referenced alphabetically for build performance. The plugin dll has a list of #pragma comment(lib, “vtk….lib”) statements to link VTK into the plugin. I know the order of these libs is significant and possibly incorrect. The crash is not as bad if vtkCommonCore is the first item in the pragma list; no other position appears to have any effect. This list has been ordered according to the resolution order used when cmake compiles VTK from source, building a test project with the same modules and using that order, and alphabetically, all with no further effect.
Does anyone have any ideas to try and get VTK to properly clean up memory and close properly?