windows_intermodule_singleton breaks when calling a Debug dll from a Release executable

[Lars Hagström <lars@…>]

A simplified example of what goes wrong (the reality is more complex, and also very difficult for me to change):

On Windows I have an exe and a dll that both use boost.interprocess. The dll interface is C-like, so that the exe and dll can use different runtimes (i.e. Debug and Release runtimes). This works fine as long as I comment out the BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME define in workaround.hpp. But if I leave that define in the code I will get random access violations deep inside the tmp_folder function (or one of the other functions in tmp_dir_helpers).

I believe that this is due to the windows_intermodule_singleton, which is only used when ...HAS_KERNEL_BOOTTIME is defined. This singleton will get created in one runtime and then accessed in another, which does not work since it contains a std::map, which is an STL object that is not possible to pass between runtimes in Visual C++.

If it is possible to fix this that would be great, but the other option would be a "nicer" way to turn off the singleton without having to patch one of the boost headers.

[Ion Gaztañaga]

Boost 1.56 replaces std::map with boost::container::map so maybe now you can mix runtimes.

[lars@…]

Yes, this seems to work now! Thanks!

[Ion Gaztañaga]

Thanks for the report, closing the issue.

[emil.styrke@…]

Replying to igaztanaga:

Boost 1.56 replaces std::map with boost::container::map so maybe now you can mix runtimes.

What if I have an application with two modules that use different versions of Boost (For example one uses 1.55 and one uses 1.56)? I tried reading the code but I can't really tell if there is any versioning mechanism in place.

The practical case: we use Boost in a shared library that we sell to customers. A customer might use other third-party libraries that in turn use Boost of a different version.

[sakhnik@…]

I believe the last comment raises a valid concern. If I have an extensive dll-based plugin system, where different ones are linking with different versions of boost, it gets impossible to debug when using boost::interprocess.