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<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.
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<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.
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 <boost/config.hpp> // Gets brought in early so that any Carbon presence doesn't influence // its configuration. #endif #ifdef __OBJC__ #import <Cocoa/Cocoa.h> #endif If you're doing just Carbon, then do your #include <Carbon/Carbon.h> after boost/config.hpp is included (in place of the #ifdef __OBJC__ block). The real gremlin here is this bit of code in boost/config/platform/macos.hpp: # ifndef TARGET_CARBON # include <boost/config/posix_features.hpp> # endif There is a posting that discusses the rationale of the above: http://lists.boost.org/boost-users/2004/10/8110.php and also makes the observation that there's probably a better way to check for MSL. My recommendation is to check for the definition of __MSL__. Thus the above code becomes: # ifndef __MSL__ # include <boost/config/posix_features.hpp> # endif IMHO the existing MSL check is a bug (checking TARGET_CARBON is too broad) and will be a trap for all Cocoa/Carbon programmers wanting to use boost. I would also think that the reality now is that most people use xcode/gcc and not CodeWarrior/MSL (this is from someone who used to use CW and MSL all the time). Thus, the motivation for addressing the issue should now be high. 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. Cheers, -C
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