From: Christopher Hunt (huntc_at_[hidden])
Date: 2005-08-01 19:52:34
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.