Subject: Re: [Boost-users] boost::interprocess on FreeBSD 7
From: Andy Wiese (andyw_at_[hidden])
Date: 2008-12-20 19:06:05
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_containers.html#interprocess.allocators_containers.containers_explained
>
> 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;content-type=text%2Fplain
>
> 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?