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