I have some more information and a work-around. I can now reproduce this problem in my Obj-C program with the following code: typedef checked_array_deleter<unsigned short> deleter; detail::sp_counted_base_impl<unsigned short, deleter>* theP = new detail::sp_counted_base_impl<unsigned short, deleter>(0, deleter()); However if I define either BOOST_SP_USE_QUICK_ALLOCATOR or BOOST_SP_USE_STD_ALLOCATOR then all is well. :-) Here's my new stack trace for when things don't go well: #0 0x90012d68 in pthread_mutex_init #1 0x00088484 in boost::detail::lightweight_mutex::lightweight_mutex() at lwm_pthreads.hpp:47 #2 0x00088084 in boost::detail::lightweight_mutex::lightweight_mutex() at lwm_pthreads.hpp:49 #3 0x00087c24 in boost::detail::sp_counted_base::sp_counted_base() at shared_count.hpp:98 #4 0x00086674 in boost::detail::sp_counted_base::sp_counted_base() at shared_count.hpp:99 #5 0x00097f64 in boost::detail::sp_counted_base_impl<unsigned short, boost::checked_array_deleter<unsigned short>
::sp_counted_base_impl(unsigned short, boost::checked_array_deleter<unsigned short>) at shared_count.hpp:253 #6 0x00097f0c in boost::detail::sp_counted_base_impl<unsigned short, boost::checked_array_deleter<unsigned short> ::sp_counted_base_impl(unsigned short, boost::checked_array_deleter<unsigned short>) at shared_count.hpp:253
This thus looks like something to do with allocators and sp_counted_based_impl... I don't see that my Obj-C environment has set up anything interesting by the way of allocators, and I did create a brand-new Obj-C project to see if I could reproduce the problem - I couldn't... however I'm thinking that this might well have something to do with Obj-C... Any ideas? Also, if I'm to define BOOST_SP_USE_QUICK_ALLOCATOR or BOOST_SP_USE_STD_ALLOCATOR then which is best? I've been unable to find documentation on the use of these defines. Thanks for your help. Cheers, -C On 30/07/2005, at 9:28 AM, Christopher Hunt wrote:
When UTFStringHolder is instantiated, I get an EXC_BAD_ACCESS and my stack trace shows that pthread_mutex_init is being called. Here's the complete stack trace:
#0 0x90012730 in _pthread_mutex_init #1 0x00088424 in boost::detail::lightweight_mutex::lightweight_mutex() at lwm_pthreads.hpp:47
These things usually happen when you have inconsistent definitions of BOOST_HAS_THREADS in the source files or libraries that form your program. Does the code still fail when you try it as a single self-contained source file? If it does, can you post a minimal example that fails? Unfortunately it is not reproducible in a single self-contained file... which is interesting isn't it...
Also, I've managed successfully to have a shared_array member as part of another class's instantiation. The only difference that I see is the timing of when they're instantiated.
Could it be anything to do with the initialisation of my pthread environment? (what initialises pthreads?) I'll do some experiments around this. If it is of interest, this is all being done in a Mac OS X Cocoa Objective-C environment. Cocoa likes to know when it is going multi-threaded (http://developer.apple.com/documentation/Cocoa/Conceptual/ Multithreading/articles/CocoaDetaching.html) and I do let it know, but maybe I should let it know earlier.
Thanks for your help. I'll do some more experimentation around the timing of instantiation.