crash in boost::interprocess::shared_memory_object if use /MTd about interprocess HOT 4 CLOSED

Hi,
if I use /MTd the crash happens. But if I call FreeLibrary in reverse order to LoadLibrary the crash does not happen.
The debugger shows me that the crash is always somewere in boost::interprocess.

Christian

from interprocess.

I have got the same issue right now!

Crash appears inside

intermodule_singleton_common.hpp

inside function

static void atexit_work()
   {
      intermodule_singleton_common<ThreadSafeGlobalMap>::finalize_singleton_logic
         (this_module_singleton_ptr, this_module_singleton_initialized, singleton_destructor);
   }

this function called twice - cos std::atexit - called twice inside 2 different dlls
so two singletons were created - ...i suppose this sigletons use some shared resources(may be pointers) - as result new and delete called for different memory managers

from interprocess.

Hi,
I think I solved the issue (maybe just for me). The problem isn't the /MTd switch of the compiler.
I think the problem is related to the singleton implementation inside boost::interprocess::shared_memory_object. My project structure is as follows:

An EXE file loads a DLL (a driver wrapper) which can load several device driver DLLs in parallel. Two of the driver DLLs are using their own shared_memory_object's as described in the doc and it work in both cases. Until I call FreeLibrary for the driver DLLs. In that case always the second FreeLibrary crashes (but not with /MDd I didn't understand this seconds fact, sorry).

I solved the issue by creating a boost::interprocess::shared_memory_object inside the driver wrapper DLL. I just instantiate such an object and in the next line I remove it. If I do this, my DLLs don't crash any more.

I hope this helps the developer of boost::interprocess.

Kind regards,
Christian

from interprocess.

My mistake was not related to boost or compiler flags nor something else of the above. I used thread synchronisation mechanisms during unloading the DLLs (PROCESS_DETACH in dll_main()). As mentioned in the Microsoft documentation this results in an undefined behaviour of the application! After redesigning my DLLs the shared_memory_objects and the entire software works stable. Maybe this helps someone.

from interprocess.