It seems that Boost has different binary layouts of its data structures when compiled with MSVC and MINGW, i.e., they’re not compatible between the two compilers. The result is therefore not unexpected. MAYBE it’s possible to make it work (e.g., compile MSVC code in Release mode), but 1) I wouldn’t bet on it, 2) even if you get it to work it’ll be extremely fragile.
* Stian
From: Boost-users On Behalf Of Da Xu via Boost-users
Sent: Sunday, March 1, 2020 00:53
To: Boost-users@lists.boost.org
Cc: Da Xu
Subject: [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 trace
dll!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!!
