Re: Shared memory between Visual Studio build and MinGW build

From: Stian Zeljko Vrba (vrba_at_[hidden])
Date: 2020-03-02 08:10:58

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 <boost-users-bounces_at_[hidden]> On Behalf Of Da Xu via Boost-users
Sent: Sunday, March 1, 2020 00:53
To: Boost-users_at_[hidden]
Cc: Da Xu <djsignal7_at_[hidden]>
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_lock<boost::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_lock<boost::interprocess::interprocess_recursive_mutex>::scoped_lock<boost::interprocess::interprocess_recursive_mutex>(boost::interprocess::interprocess_recursive_mutex & m) Line 81 C++
dll!boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,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<boost::interprocess::ipcdetail::index_config<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>>> & index, boost::interprocess::ipcdetail::bool_<1> is_intrusive) Line 1076 C++
dll!boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,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<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>::generic_construct<SharedMem_Info>(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<boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>,SharedMem_Info,0>::operator()<char const (&)[17],int,int,int,int,bool,boost::interprocess::allocator<void,boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>> &>(const char[17] & <args_0>, int && <args_1>, int && <args_2>, int && <args_3>, int && <args_4>, bool && <args_5>, boost::interprocess::allocator<void,boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>> & <args_6>) 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!!