Re: [Boost-users] shared_array EXC_BAD_ACCESS
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. Cheers, -C
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 ::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 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.
I forgot to mention one other (important) thing: I'm using libgmalloc (http://developer.apple.com/documentation/Darwin/Reference/ManPages/ man3/libgmalloc.3.html). When I don't use this guard-malloc approach, all is well. :-P -C On 02/08/2005, at 10:52 AM, Christopher Hunt wrote:
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
* theP = new detail::sp_counted_base_impl (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
::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
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.
OK, this is now completely solved. :-)
Interestingly, boost/detail/lightweight_mutex.hpp was being included in
one place and declaring lightweight_mutex from
boost/detail/lwm_nop.hpp. However the implementation from
boost/detail/lwm_pthreads.hpp was actually being used.
To cut a long story short, declaring a prefix file that forced boost to
configure itself prior to importing Cocoa and Carbon dependencies
completely solved the problem. Here's what my Cocoa pch file looks
like:
//
// Prefix header for all source files
//
#ifdef __cplusplus
#include
Christopher Hunt wrote:
What needs to be done to fix the problem? I'm willing to help to save some other poor soul from spending a day or two stuffing around.
I've forwarded your post to the developer list, hopefully John Maddock (the Boost.Config maintainer) or someone with Mac OS X access will look into it.
participants (2)
-
Christopher Hunt -
Peter Dimov