0

The code below creates and reads a file called MyMappedFile. If I run the write code on Linux (Ubuntu 14.04), I can copy this file to other Linux machines and it reads fine. If I instead transfer it to OSX and attempt to run the read code on it, I get an error:

libc++abi.dylib: terminating with uncaught exception of type boost::interprocess::lock_exception: boost::interprocess::lock_exception

Conversely, files written on OSX are able to be read on OSX. But attempting to read them under Linux gives me a similar message:

terminate called after throwing an instance of 'boost::interprocess::lock_exception'
  what():  boost::interprocess::lock_exception

The resulting files are different.

I'm writing with this code:

#include <boost/interprocess/managed_mapped_file.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/containers/string.hpp>

namespace bip=boost::interprocess;

typedef bip::managed_shared_memory::segment_manager segment_manager_t;
typedef bip::basic_string<char, std::char_traits<char>, bip::allocator<char, segment_manager_t> > shared_string;

int main() {
  bip::managed_mapped_file *outfile = new bip::managed_mapped_file(bip::create_only, "MyMappedFile", 1000);
  outfile->find_or_construct<shared_string>("mystring")("bubza", outfile->get_segment_manager());
  outfile->flush();
}

And reading with this:

#include <boost/interprocess/managed_mapped_file.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/containers/string.hpp>

namespace bip=boost::interprocess;

typedef bip::managed_shared_memory::segment_manager segment_manager_t;
typedef bip::basic_string<char, std::char_traits<char>, bip::allocator<char, segment_manager_t> > shared_string;

int main() {
  bip::managed_mapped_file *infile = new bip::managed_mapped_file(bip::open_only, "MyMappedFile");
  shared_string *ptr = infile->find_or_construct<shared_string>("mystring")(infile->get_segment_manager());
  std::cout << "I got " << *ptr << std::endl;
}

Both machines are using GCC 4.8 (4.8.4 on Linux, 4.8.5 on OSX) and Boost 1.55.

Why aren't the files compatible between these platforms?

Please note that I'm talking about the MyMappedFile data file produced by the writing code. The executables produced by compiling the code are not being transferred between machines: the Linux code is compiled on a Linux machine, and the OSX code is compiled on the OSX machine.

Allen Luce
  • 7,859
  • 3
  • 40
  • 53
  • `Why aren't the files compatible between these platforms?` Please share some examples, we can not guess. Typical reasons include endianess, or different locale if you are using the standard streams. – sbabbi Mar 24 '16 at 10:10
  • You can find the file written on Linux at http://so.con.com/MyMappedFile.linux and the one written on OSX at http://so.con.com/MyMappedFile.osx – Allen Luce Mar 24 '16 at 15:35
  • Both Linux and OSX are little-endian, and it doesn't appear from a quick scan of the files that endianness is an issue. Please note that the code above is the totality of what's involved, so if standard streams are being used it's done by Boost, not my code. But I would expect Boost to be using `mmap()` and not streams. – Allen Luce Mar 24 '16 at 15:39

1 Answers1

0

RE: Why aren't the files compatible between these platforms?

OS X and Linux utilize different kernels and ABI's, so they compile code in differently. Linux generally uses ELF file formats, while OS X uses Mach-O, which are platform specific.

EDIT: No idea why your output is different (it was not shared).

l'L'l
  • 44,951
  • 10
  • 95
  • 146
  • How specifically does this cause Boost to write different output on different platforms? – Allen Luce Mar 23 '16 at 22:00
  • Not sure I follow... as your code throws a `std:exception` instead when trying to execute it on a platform it wasn't compiled for. – l'L'l Mar 23 '16 at 22:05
  • When did I say anything about output being different? – l'L'l Mar 23 '16 at 22:11
  • I referring specifically to the errors, nothing else, nothing more. Your question was: "Why aren't the files compatible between these platforms?" Which i assumed meant the executables... – l'L'l Mar 23 '16 at 22:13
  • And unfortunately I don't have time to "chat" right now. – l'L'l Mar 23 '16 at 22:17
  • You say you're trying to execute an ELF compiled binary on OS X and vice versa, do you seriously expect that to work? good luck with that. – l'L'l Mar 23 '16 at 22:22
  • 1
    @DougLuce what makes you say ABI is not it. Because that's 100% it. Use portable serialization if you need it. – sehe Mar 23 '16 at 22:24
  • 1
    As I understand OP's question, he is trying to open the file written to in Linux in OSX, not run the executable for one platform on the other. However, it might still be a question of ABI if the boost inter process classes use OS-specific facilities, so as @sehe said you should use serialisation instead of IPC. – Javier Martín Mar 23 '16 at 22:37
  • Sorry, I guess it wasn't clear -- the file is `MyMappedFile` as produced by `managed_mapped_file`. I am not transferring executables. The write code will produce `MyMappedFile`, and the read code will read it. – Allen Luce Mar 23 '16 at 23:33