Hi all,
I am writing all of this down because I was only able to find cryptic
references to this problem in the Boost archives, and in the Apple
Xcode-Users archives. I also want to ask whether my solution to the
problem makes sense.
I am developing a cross platform static library on OSX 10.4.2 using
Xcode 2.1. The Xcode IDE includes a mechanism for unit testing that I am
using. The unit test target is setup by Xcode, and one of the things it
does is to include Carbon.h as a "prefix include". This means that the
compiler command line includes "-include <path>/Carbon.h" and this
header file is read BEFORE anything else.
Everything had been going great until I wrote a test using
boost::shared_ptr. I began to see all sorts of strange behaviors. After
a while I turned on Guard Malloc in the debugger. That was when it
started catching bad access errors in pthread_mutex_init, which was
being called as a result of creating a boost:shared_ptr. It turns out
that in the constructor for:
template shared_count(P p, D d)
it executes this:
pi_ = new sp_counted_base_impl(p, d);
Class sp_counted_base_impl is derived from sp_counted_base, and
sp_counted_base has a data member declared as:
#if defined(BOOST_HAS_THREADS) || defined(BOOST_LWM_WIN32)
mutable mutex_type mtx_;
#endif
In the constructor for sp_counted_base, the constructor for mutex_type
(lightweight_mutex) was being called. It in turn called
pthread_mutex_init, passing the address of its mutex member, which is a
44 byte buffer.
The memory access problem, though, is that when operator new called
malloc, it did so as if sp_counted_base did NOT contain the mutex data
member. This means that the 44 byte buffer wasn't allocated, and because
Guard Malloc is very clever, the access outside of the allocated space
was caught.
I searched around and found messages where people said they saw problems
like this because the Carbon headers were included before the Boost
headers. This certainly fit my situation. I managed to change the order
of header inclusion and everything started working. The class memory was
allocated including space for mtx_ and the mutex init worked. This is
really a lousy solution, though, so I kept poking around.
I put things back so that Carbon.h was included on the command line, and
assumed I would need to live with that. I added -DBOOST_HAS_THREADS to
my compiler flags. The test still failed because the mutex memory had
not been allocated. Because of this, I looked for anywhere where
BOOST_HAS_THREADS could be #undef-ed. I found two possibilities, both in
boost/config/suffix.hpp. It appeared that in my case BOOST_HAS_PTHREADS
was not defined. This led me to boost/config/macos.hpp. I found this
little code snippet:
//
// BSD runtime has pthreads, sigaction, sched_yield and gettimeofday,
// of these only pthreads are advertised in , so set the
// other options explicitly:
//
# define BOOST_HAS_SCHED_YIELD
# define BOOST_HAS_GETTIMEOFDAY
# define BOOST_HAS_SIGACTION
I tried including ahead of shared_ptr.hpp, but that still
failed the same way.
I edited macos.hpp and added a fourth #define to this section:
# define BOOST_HAS_PTHREADS
When I built with the modified header, everything worked as expected.
The mutex space was allocated. I don't want to change the Boost headers,
though, so undid the change to macos.hpp. I went back to my test target
in Xcode and changed the compiler flag -DBOOST_HAS_THREADS to
-DBOOST_HAS_PTHREADS. I rebuilt my test code and everything works perfectly.
So it *appears* that defining BOOST_HAS_PTHREADS on the compiler command
line is the general case solution for this problem, but I'm looking for
opinions more expert than mine. If this is indeed true, then does anyone
know why the macro isn't just defined in
boost/config/platform/macos.hpp? Have I opened myself up to other
problems by doing this? Any help would be appreciated.
- Rush
