On Dec 17, 2008, at 10:39 AM, Ion Gaztañaga wrote:
Andy Wiese wrote:
Using boost::interprocess from boost_1_37_0 on FreeBSD 7.0, I get a segmentation fault in pthread_mutex_lock() from /lib/ libthr.so.3, in what appears to anything related to a ShmemAllocator. For example, when I run the example from http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/allocators_contai...
I haven't never tried FreeBSD 7.0 so I don't even know if it is properly detected so that emulation code is used instead of native process-shared mutexes. Googling around, it seems that FreeBSD does not support process-shared mutexes, and the header unistd.h from FreeBSD:
http://www.freebsd.org/cgi/cvsweb.cgi/src/include/unistd.h?rev=1.80.2.1.2.1;...
seems to define _POSIX_THREAD_PROCESS_SHARED to -1, which is handled in boost/interprocess/detail/workaround.hpp to use emulation instead of pthread calls? Can you help me with this?
FreeBSD it's on my to-do list but I don't know when I'll have time to download, install and test it with Interprocess :-(
Please, try to get the latest SVN code for latest bugs and try to define
BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION to avoid using pthread calls. But we must also see why FreeBSD configuration is not properly detected.
Regards,
Ion
Ion, Thank you so much for your willingness to help. I will be happy to help any way I can to test and debug the FreeBSD configuration if you can keep up the suggestions. I have to do this work as a sideline to some other major deliverables for the next couple weeks, so I apologize for the lag but will try be as responsive as I can. I tried your suggestion and had these two results: boost_trunk: When I switched to trunk I ran into a linking problem that stopped me (on both OS-X GCC 4.0.1 and FreeBSD GCC 4.2.1 ) I build a library in this project, and between the test app and the lib I get a duplicate symbol error in boost::interprocess:file_mapping::swap. I've had this problem a lot when moving code from gcc 3 to 4. There must be some trick to getting inline functions to be properly merged that I just don't understand. I've always ended up putting the function bodies out of the template files. So whatever the correct resolution to that problem is, I went back to boost_1_37_0 for these tests. On os-x the error looks like: ld: duplicate symbol boost ::interprocess ::file_mapping::swap(boost::interprocess::file_mapping&)in /Users/andy/ Projects/5.0/src/query-engine/cxdb/build/Debug/ libcxdb.a(PropertyIndex.o) and /Users/andy/Projects/5.0/src/query- engine/cxdb/build/cxdb.build/Debug/test_cxdb.build/Objects-normal/i386/ test_cxdb.o BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION On FreeBSD with GCC 4.2.1: This option did change the behavior. It now throws BAD_ACCESS in atomic_cas32, instead of in the pthread mutex. The stack trace from gdb: #0 0x080a164e in boost::interprocess::detail::atomic_cas32 (mem=0x284d1004, with=1, cmp=0) at atomic.hpp:115 #1 0x080b92a1 in boost::interprocess::interprocess_mutex::lock (this=0x284d1004) at interprocess_mutex.hpp:33 #2 0x080b92f2 in scoped_lock (this=0xbfbfe23c, m=@0x284d1004) at scoped_lock.hpp:78 #3 0x080b931f in boost ::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0>::deallocate (this=0x284d1004, addr=0x284eca48) at rbtree_best_fit.hpp:1267 #4 0x080b9388 in boost ::interprocess ::segment_manager_base < boost ::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0> >::deallocate (this=0x284d1004, addr=0x284eca48) at segment_manager.hpp:216 #5 0x080b93bb in boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost ::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0>, boost::interprocess::iset_index> >::deallocate (this=0xbfbfe394, ptr=@0xbfbfe2c0) at allocator.hpp:156 #6 0x080b9420 in boost ::interprocess ::detail::basic_string_base<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost ::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0>, boost::interprocess::iset_index> > >::deallocate (this=0xbfbfe394, p=@0xbfbfe2c0, n=40) at string.hpp:309 #7 0x080b946f in boost ::interprocess ::detail::basic_string_base<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost ::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0>, boost::interprocess::iset_index> > >::deallocate_block (this=0xbfbfe394) at string.hpp:341 #8 0x080b9491 in ~basic_string_base (this=0xbfbfe394) at string.hpp:119 #9 0x080b94d1 in ~basic_string (this=0xbfbfe394) at string.hpp:621 #10 0x2819e9a1 in PropertyIndex::addValueId (this=0x285073e0, valueKey=0x2850744c "another value 40", id=0x80c5a06 "6", mayGrow=true) at PropertyIndex.cpp:222 #11 0x08097fb6 in test_index::operator() (this=0xbfbfe8bd) at test_cxdb.cpp:598 I ran the libs/config/configure script, but this didn't change the behavior. Any next suggestions?