[boost] [Interprocess] Loosing shared memory when exiting scope

Subject: [boost] [Interprocess] Loosing shared memory when exiting scope
From: supplier (supplier_at_[hidden])
Date: 2011-02-22 06:22:17

Hi there,

at the moment I'm working on a Windows application, which uses Boost.Interprocess library to share data between two processes. The general approach is as follows: 
  - start application A
  - start application B
  - create shared memory in A using 'wmanaged_windows_shared_memory'. The line of code would look like this:

     > sharedMemory = new wmanaged_windows_shared_memory(create_only, mName.c_str(), mSize);
    
  - connect B to shared memory using the 'open_only' argument for the line above (size is not 
    needed when connecting)
  - then B creates data objects in the shard memory using offset pointers and when finished 
    removes his references to the shared memory by deleting the 'wmanaged_windows_shared_memory' object
  - application A will then read these objects and when finished it will also
    delete his 'wmanaged_windows_shared_memory' object to remove all references and allow windows to 
    free the allocated shared memory

To enable Windows to free the shared memory I had to ensure that all references to this were removed. This was a little work, because at first not all references to the shared memory were freed by application B. In order to do so I replaced the existing Singleton with RII objects [1] to ensure all references are deleted when a well defined scope of application B is left.
Using the RII objects some passages of the code look like the following example:
   
 1   >    [...]
 2   >    // We are in class B of application B, which does work with the shared memory
 3   >    // Connecting to the existing shared memory
 4   >    SharedMemoryRiiConnector shmem("Some Name");
 5   > 
 6   >    // Do some stuff here, for example calling a function creating objects
 7   >    TypeR* instance = createObjectInSharedMemory();
 8   >
 9   >    // Call a member function of TypeR
10   >    instance->doSomething();
11   >    [...]
12   >  }
13   >
14   > TypeR* classB::createObjectInSharedMemory()
15   > {
16   >    // Connect to the shared memory again to allow working in this 
17   >    SharedMemoryRiiConnector shmem("Some Name");
18   >    
19   >    // Create an object in the shared memory using the interface of the
20   >    // RII object, which uses the Boost.Interprocess functions to handle allocation
21   >    TypeR* instance = shmem.createObject<TypeR>("Example Object");
22   >    return instance;
23   > }
24   >

There is one thing I do not understand so far: When returning from 'createObjectInSharedMemory()' there are cases when the pointer to 'instance' is valid within 'createObjectInSharedMemory()' but gets invalid as far as returned to the caller function in line 7. In this case the application would crash in line 10, although a connection was build up in line 4.
This issue seems somehow to be connected to the destruction of the 'shmem' object in line 22, which deletes his instance of the 'wmanaged_windows_shared_memory' and with this seems to invalidate the shared memory context of the caller, too. On the opposite using one RII object as member in classB would work as expected.

Why is this? I would expect the call in line 10 to succeed. My feeling tells me that this is due to the mechanism mapping the data of the shared memory into local address space. Although I did not found any information regarding my issue. Please explain this behavior to me.

Best regards,
Sören Kewenig

[1] http://www.hackcraft.net/raii/