Opened 8 years ago
Last modified 8 years ago
#10581 new Bugs
Conflict when using boost::interprocess objects when linking to 2 different boost versions
Reported by: | Yochai Timmer | Owned by: | Ion Gaztañaga |
---|---|---|---|
Milestone: | To Be Determined | Component: | interprocess |
Version: | Boost 1.55.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Introduction: Boost interprocess directory and file naming has changed after boost 1.54. Intreprocess communication does not work between version greater than 1.54 and lower than 1.54. Related bug report: https://svn.boost.org/trac/boost/ticket/9767
The Scenario: Compile a .dll that uses some shared memory object from the boost::interprocess library with version 1.55. (Think of this as an external 3rd party dll which you have no control over). Then make another project, using an older version of boost, lets say boost 1.51. In the new project, open a shared memory object, then call a function from the dll that also opens a shared memory object. This should have opened 2 shared memory objects, one with the 1.55 version and one with the 1.51 version.
The problem is that the second memory object will always fail (even if you change the order).
The Problem: Boost uses a singleton object to map the open interprocess memory objects. Because of the versions mismatch, the first shared memory object that is created, also creates the map (And with it the file naming convention).
Solution: The singleton should just map the items, but use the functions according to the calling binary and compiled version of the caller.
Workaround: I've just changed the names in the singleton object. I figured you can't have redundancy if it's incompatible, so lets have a separate memory mapping. In windows_intermodule_singleton.hpp changing the windows_semaphore_based_map named objects for the 1.55 version will keep the map separated.
Change History (2)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
The folder name is different, and in the older versions the file name was decorated by boost.
Create 2 projects, a DLL and an executable. Link one project to boost 1.54 or older (i used 1.51), and the other to boost 1.55.
Then use the exact same code (different classes for a different name, the fact that you cant use the same shared memory object is another issue).
//in Dll1 struct Test1 { static void OpenSharedMemory() { boost::interprocess::message_queue sh(boost::interprocess::open_or_create, "Test1", 20,24); } } //in The executable struct Test2 { static void OpenSharedMemory() { boost::interprocess::message_queue sh(boost::interprocess::open_or_create, "Test2", 20,24); } }
Now call them in the main function, the second call will always fail (you can change the order).
int main(int argc, char* argv[]) { Test1::OpenSharedMemory(); Test2::OpenSharedMemory(); return 0; }
But isn't just a problem of file naming convention ? Technically you can specify the name of the shared object ... and it's not decorated at all by boost. Could you give me an example ... isn't just because you changed compiler between both and allocate string instead of array of char ?