Ion, thank you for your reply. As you suggested mmap returns a different address than the one specified, behaving as a named_shared_object under the hood instead of a fixed_named_shared_object. I have used the MAP_FIXED flag for mmap with disastrous results (the man pages already discourage you to use this flag). The computer hanged, very strange behaviours, etc... It just forces a segment the size you want at the address you specify overwriting anything in it's way. Lots of fun as you can foresee... So as I see it: - You cannot store raw pointers in a shared memory even if you use fixed_named_shared_object. They all have to be offset_ptr always as it may not map where you want. - Documentation under 'Using STL containers and mapping the memory at a fixed address' should reflect this. A possible workaround, as you suggested, would be to somehow write down the address where the memory was mapped to so that other processes know about it. IMHO this is a named_shared_object in the end, so why use fixed_named_shared_object? I think that due to the inner behavior of mmap as long as you are aware that a fixed_named_shared_object is in fact an OCCASIONALY_fixed_named_shared_object everything sould be alright. Notice that the same binary run twice on the same box may map to a different address each time which may or may not be the one specified! And even if it returns false during creation of the segment you have already screwed your box overwritting protected memory areas... Do you agree or have I got the wrong end of the stick? (I use Linux Fedora Core 5)