简体   繁体   中英

Reading Shared Memory from x86 to x64 and vice versa on OSX

If I create a SM from 64 bit application and open it on 32 bit application it fails.

//for 64 bit
    shared_memory_object( create_only, "test" , read_write) ; 
// for 32 bit
    shared_memory_object (open_only, "test", read_write);

file created by 64bit application is at path as below:

/private/tmp/boost_interprocess/AD21A54E000000000000000000000000/test

where as file searched by 32 bit application is at path

/private/tmp/boost_interprocess/AD21A54E00000000/test

Thus 32 bit applications cannot read the file.

I am using boost 1.47.0 on Mac OS X. Is it a bug? Do I have to do some settings use some Macros in order to fix it? Has any one encountered this problem before?

Is it important that the shared memory be backed by a file? If not, you might consider using the underlying Unix shared memory APIs: shmget, shmat, shmdt, and shmctl, all declared in sys/shm.h. I have found them to be very easy to use.

// create some shared memory
int id = shmget(0x12345678, 1024 * 1024, IPC_CREAT | 0666);

if (id >= 0)
{
    void* p = shmat(id, 0, 0);

    if (p != (void*)-1)
    {
        initialize_shared_memory(p);

        // detach from the shared memory when we are done;
        // it will still exist, waiting for another process to access it
        shmdt(p);
    }
    else
    {
        handle_error();
    }
}
else
{
    handle_error();
}

Another process would use something like this to access the shared memory:

// access the shared memory
int id = shmget(0x12345678, 0, 0);

if (id >= 0)
{
    // find out how big it is
    struct shmid_ds info = { { 0 } };

    if (shmctl(id, IPC_STAT, &info) == 0)
        printf("%d bytes of shared memory\n", (int)info.shm_segsz);
    else
        handle_error();

    // get its address
    void* p = shmat(id, 0, 0);

    if (p != (void*)-1)
    {
        do_something(p);

        // detach from the shared memory; it still exists, but we can't get to it
        shmdt(p);
    }
    else
    {
        handle_error();
    }
}
else
{
    handle_error();
}

Then, when all processes are done with the shared memory, use shmctl(id, IPC_RMID, 0) to release it back to the system.

You can use the ipcs and ipcrm tools on the command line to manage shared memory. They are useful for cleaning up mistakes when first writing shared memory code.

All that being said, I am not sure about sharing memory between 32-bit and 64-bit programs. I recommend trying the Unix APIs and if they fail, it probably cannot be done. They are, after all, what Boost uses in its implementation.

I found the solution to the problem and as expected it is a bug.

This Bug is present in tmp_dir_helpers.hpp file.

    inline void get_bootstamp(std::string &s, bool add = false)
    {
      ...
       std::size_t char_counter = 0;
       long  fields[2] = { result.tv_sec, result.tv_usec };
       for(std::size_t field = 0; field != 2; ++field){
          for(std::size_t i = 0; i != sizeof(long); ++i){
             const char *ptr = (const char *)&fields[field];
             bootstamp_str[char_counter++] = Characters[(ptr[i]&0xF0)>>4];
             bootstamp_str[char_counter++] = Characters[(ptr[i]&0x0F)];
          }
       ...
    }

Where as it should have been some thing like this..

**long long** fields[2] = { result.tv_sec, result.tv_usec };
           for(std::size_t field = 0; field != 2; ++field){
              for(std::size_t i = 0; i != sizeof(**long long**); ++i)

I have created a ticket in boost for this bug.

Thank you.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM