Boost C++ Libraries: Ticket #5108: shared memory object temporary name bug, Mac OSX 10.6.6 https://svn.boost.org/trac10/ticket/5108 <p> There is a problem with creating a shared memory object in a 64 bit application and trying to open it in a 32 bit application. The problem seems to stem from the following snippet of code, found in the function get_bootstamp defined on line 50 of the file tmp_dir_helpers.hpp. </p> <pre class="wiki"> 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 *)&amp;fields[field]; bootstamp_str[char_counter++] = Characters[(ptr[i]&amp;0xF0)&gt;&gt;4]; bootstamp_str[char_counter++] = Characters[(ptr[i]&amp;0x0F)]; } } </pre><p> On my system sizeof(long) = 4 under a 32 bit application, and sizeof(long) = 8 on a 64 bit application. Hence the generated temporary filename stored in bootstamp_str is of differing lengths under a 32 bit app and a 64 bit app respectively. Hence, I was seeing the error "file or directory does not exist" when trying to open a named shared memory object. </p> <p> The fix (cross platform?) seems to be to use the type "long long" because sizeof(long long) = 8 under 32 and 64 bit application. </p> <pre class="wiki"> std::size_t char_counter = 0; 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){ const char *ptr = (const char *)&amp;fields[field]; bootstamp_str[char_counter++] = Characters[(ptr[i]&amp;0xF0)&gt;&gt;4]; bootstamp_str[char_counter++] = Characters[(ptr[i]&amp;0x0F)]; } } </pre><p> Making this change fixed this problem for me. Hope this helps! </p> <p> David </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/5108 Trac 1.4.3 David Ibbitson <david.ibbitson@…> Sat, 22 Jan 2011 16:40:13 GMT <link>https://svn.boost.org/trac10/ticket/5108#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/5108#comment:1</guid> <description> <p> It looks like ticket <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/4251" title="#4251: Bugs: Interprocess failed to communicate in OS X 10.5.8 Leopard under 64 bit mode (closed: fixed)">#4251</a> is related if not the same issue. </p> </description> <category>Ticket</category> </item> <item> <author>david.ibbitson@…</author> <pubDate>Sun, 23 Jan 2011 23:56:53 GMT</pubDate> <title>severity changed https://svn.boost.org/trac10/ticket/5108#comment:2 https://svn.boost.org/trac10/ticket/5108#comment:2 <ul> <li><strong>severity</strong> <span class="trac-field-old">Problem</span> → <span class="trac-field-new">Showstopper</span> </li> </ul> Ticket david.ibbitson@… Mon, 24 Jan 2011 20:44:17 GMT attachment set https://svn.boost.org/trac10/ticket/5108 https://svn.boost.org/trac10/ticket/5108 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">main.cpp</span> </li> </ul> <p> Program demonstrating Leopard sysctl bug. </p> Ticket david.ibbitson@… Mon, 24 Jan 2011 20:45:23 GMT <link>https://svn.boost.org/trac10/ticket/5108#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/5108#comment:3</guid> <description> <p> Another update. It appears that on Leopard the sysctl function periodically returns an invalid timeval struct under a 64 bit build. In particular the microsecond field is occasionally incorrect. See the attached file for a sample program that shows the issue. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Ion Gaztañaga</dc:creator> <pubDate>Fri, 01 Apr 2011 18:51:14 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/5108#comment:4 https://svn.boost.org/trac10/ticket/5108#comment:4 <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