Re: [Boost-users] boost::interprocess on FreeBSD 7

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?