https://svn.boost.org/trac10/ticket/4251 <p> This issue only exists explicitly for OSX leopard 64 bits application trying to use IPC. </p> <p> Windows 32/64 bits, XP, Vista, Win 7 has no issue and OSX 10.4: 32 bits, 10.5: 32 bits, 10.6: 32/64 bits all works fine. </p> <p> The issue is due to "inline void get_bootstamp(std::string &amp;s, bool add = false)" function. </p> <p> When a 64 bits host application create the shared_memory_object, there will be a folder somewhat like "33FABFC2B8FACA0133FABFC2B8FACA01" being created in the boost_interprocess directory. When the 64 bits client application trying to open the created shared_memory_object, the "get_bootstamp(std::string &amp;s, bool add = false)" function will return "33FABFC2B8FACA010000000000000000", therefore, the client will always failed to find the shared memory object. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/4251 Trac 1.4.3 Ion Gaztañaga Fri, 01 Apr 2011 19:06:06 GMT https://svn.boost.org/trac10/ticket/4251#comment:1 https://svn.boost.org/trac10/ticket/4251#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Disabled bootstamp in Boost 1.47. This means that shared memory/queues will go to /tmp if it exists. If /tmp is not cleared on reboot shared memory will survive to reboots, but this behaviour is allowed by POSIX. Using bootstamps to detect reboots is doing more harm than good. </p> Ticket