[Boost-users] Shared memory between Visual Studio build and MinGW build

Hi folks, got a strange one here. I am trying to get two programs to communicate with each other on Windows 10 via shared memory. Both of them are using Boost 1.72, compiled from the same set of headers.  I am only using the shared memory portion of boost. However, one is compiled with Visual studio 2019 community, and the other one is compiled with MinGW 64, g++ version 9.2.0. I have to use MinGW, because I am writing a plugin for another program, which only takes dlls compiled with MinGW. The program compiled with MinGW creates the shared memory and allocates several objects. Then I started the second program that was compiled with Visual Studio 2019. It was able to find and connect to the managed segment. When I am viewing the segment info from Visual Studio's debugger, everything looks ok. However, when I call get_free_memory(). It spits back 18446744073709551104, which is just bizarre. Then, when I tried to find_or_construct on the managed segment. It just hangs, apparently stuck in winapi::sleep_tick()  with the following tracedll!boost::interprocess::winapi::sleep_tick() Line 1288 C++dll!boost::interprocess::ipcdetail::thread_sleep_tick() Line 187 C++dll!boost::interprocess::spin_wait::yield() Line 128 C++dll!boost::interprocess::ipcdetail::try_based_lockboost::interprocess::ipcdetail::spin_mutex(boost::interprocess::ipcdetail::spin_mutex & m) Line 71 C++dll!boost::interprocess::ipcdetail::spin_mutex::lock() Line 81 C++dll!boost::interprocess::ipcdetail::spin_recursive_mutex::lock() Line 95 C++dll!boost::interprocess::interprocess_recursive_mutex::lock() Line 165 C++dll!boost::interprocess::scoped_lockboost::interprocess::interprocess_recursive_mutex::scoped_lockboost::interprocess::interprocess_recursive_mutex(boost::interprocess::interprocess_recursive_mutex & m) Line 81 C++dll!boost::interprocess::segment_manager,0>,boost::interprocess::iset_index>::priv_generic_named_construct<char>(unsigned char type, const char * name, unsigned __int64 num, bool try2find, bool dothrow, boost::interprocess::ipcdetail::in_place_interface & table, boost::interprocess::iset_index,0>>> & index, boost::interprocess::ipcdetail::bool_<1> is_intrusive) Line 1076 C++dll!boost::interprocess::segment_manager,0>,boost::interprocess::iset_index>::priv_generic_construct(const char * name, unsigned __int64 num, bool try2find, bool dothrow, boost::interprocess::ipcdetail::in_place_interface & table) Line 760 C++dll!boost::interprocess::segment_manager,0>,boost::interprocess::iset_index>::generic_construct(const char * name, unsigned __int64 num, bool try2find, bool dothrow, boost::interprocess::ipcdetail::in_place_interface & table) Line 705 C++dll!boost::interprocess::ipcdetail::named_proxy,0>,boost::interprocess::iset_index>,SharedMem_Info,0>::operator(),0>,boost::interprocess::iset_index>> &>(const char[17] & , int && , int && , int && , int && , bool && , boost::interprocess::allocator,0>,boost::interprocess::iset_index>> & ) Line 131 C++ It looks like it the segment manager was unable to get a mutex lock on the memory? But I don't believe I put a mutex lock on the segment manager from the other end.   Everything works just fine if I am doing shared memory between two programs compiled with visual studio.  So, it feels like somewhere some how memory alignment is off?  Anybody ran into a similar issue before? Any help would be greatly appreciated! Thank you!!