Hi, yes, the RegisterXXXCoreObjectFactory() and RegisterOneFactory() style was modified to prevent exactly the same issues you experienced.
While it is always a good idea to clean-up statically constructed objects during static de-initialization of the shared libraries, this is especially important in the context of the CTK Plugin Framework (and hence the MITK Workbench). One "feature" there is that new/modified plug-ins are loaded during application start-up to cache meta-data and resources (the plug-in is not loaded by default it has already been cached and was not modified between two application runs). After the caching, it is unloaded again and with it all its dependencies which have a reference count of 1. If at some point later during the application life-time a previously cached and unloaded plug-in is loaded again (e.g. by activating a view in the MITK Workbench), the plug-in and its dependencies are loaded. This is the second time the libraries are loaded. Best, Sascha On 08/17/2014 09:24 PM, Rostislav Khlebnikov wrote: > Hi Sascha, > > seems like I found why the application crashed at startup (actually, > only the first time after rebuild!). > What I had was probably an old and deprecated way of initializing the > core object factory using a RegisterXXXCoreObjectFactory() and > RegisterOneFactory() functions with a static flag to check if > registration was already done. > Once I replaced the RegisterOneFactory() calls with having member > variables in the CoreObjectFactory, the crash started happening every time. > > Reason for that is that the module dll was loaded, then unloaded, and > then loaded again. As the CoreObjectFactory was never unregistered on > the module dll unload, this caused the crash. > So basically the solution was to create a static instance of a struct > with constructor registering the factory and destructor unregistering it > (similar to ConnectomicsObjectFactory). > > I'm still interested why the module dll is loaded twice though - could > you perhaps clarify this? > > Thanks, > Rostislav. > > On 14/08/2014 15:26, Sascha Zelzer wrote: >> Hi, >> >> this should very well be possible. Both the old way of registration >> and the activator approach happen during static initialization. A >> stack trace of your crash could shed more light on your particular >> problem. >> >> Best, >> Sascha >> >> On 08/13/2014 07:13 PM, Rostislav Khlebnikov wrote: >>> Hi guys, >>> >>> is it possible to register CoreObject-, Reader-, and Writer- factories >>> for datatypes introduced within a module using >>> US_EXPORT_MODULE_ACTIVATOR? >>> I mean it actually works, but crashes on startup sometimes. >>> >>> Rostislav. >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> mitk-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
