
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 get the segfault at this line: //Initialize the STL-like allocator const ShmemAllocator alloc_inst (segment.get_segment_manager()); I stepped back to this simple test after encountering this segfault (always in pthread_mutex_lock) when trying to use almost any function of segment_manager from managed_mapped_file. This is from an mapped file boost::interprocess::map structure that works very well on darwin. Is there any hope to getting this to work on FreeBSD? ----------------------------------------------------------------------------------------------- FWIW, here is the complete text of the example: void test_ipc2() { using namespace boost::interprocess; shared_memory_object::remove("MySharedMemory"); try{ //A managed shared memory where we can construct objects //associated with a c-string managed_shared_memory segment(create_only, "MySharedMemory", //segment name 65536); //Alias an STL-like allocator of ints that allocates ints from the segment typedef allocator<int, managed_shared_memory::segment_manager> ShmemAllocator; //Alias a vector that uses the previous STL-like allocator typedef vector<int, ShmemAllocator> MyVector; int initVal[] = {0, 1, 2, 3, 4, 5, 6 }; const int *begVal = initVal; const int *endVal = initVal + sizeof(initVal)/sizeof(initVal[0]); //Initialize the STL-like allocator const ShmemAllocator alloc_inst (segment.get_segment_manager()); //Construct the vector in the shared memory segment with the STL- like allocator //from a range of iterators MyVector *myvector = segment.construct<MyVector> ("MyVector")/*object name*/ (begVal /*first ctor parameter*/, endVal /*second ctor parameter*/, alloc_inst /*third ctor parameter*/); BOOST_CHECK(myvector); //Use vector as your want std::sort(myvector->rbegin(), myvector->rend()); // . . . //When done, destroy and delete vector from the segment segment.destroy<MyVector>("MyVector"); } catch(...){ shared_memory_object::remove("MySharedMemory"); throw; } shared_memory_object::remove("MySharedMemory"); }

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

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?

Andy Wiese wrote:
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.
Ok. I've just finished downloading 3CDs of FreeBSD but I can't tell you how much time I will need to install it in a virtual machine ;-)
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 )
It's a bug, file_mapping::swap was not marked as inline. I've just solved it in trunk.
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:
Uggh! No ideas of what might be. I'll need to install FreeBSD somewhere to test this. Thanks for the info, I'll try to bring you some good news in a few weeks. Ion

On Dec 20, 2008, at 6:34 PM, Ion Gaztañaga wrote:
Andy Wiese wrote:
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.
Ok. I've just finished downloading 3CDs of FreeBSD but I can't tell you how much time I will need to install it in a virtual machine ;-)
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 )
It's a bug, file_mapping::swap was not marked as inline. I've just solved it in trunk.
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:
Uggh! No ideas of what might be. I'll need to install FreeBSD somewhere to test this. Thanks for the info, I'll try to bring you some good news in a few weeks.
Ion
Wow. That's super cool. I have backed off my implementation to another approach which can do without the interprocess stuff, but at a great performance cost. I can make progress on my work without interprocess for a few weeks. I am far from expert in either boost or FreeBSD, but if there is anything I can do to help please let me know.

Andy Wiese wrote:
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.
Andy, I've just committed a fix in interprocess/detail/workaround.hpp to properly detect FreeBSD configuration. I've run all the tests in a FreeBSD 6 based DesktopBSD VmWare virtual machine. When you have time, just update that file and try to run tests. I suspect NetBSD and OpenBSD will need similar tweaks, but let's start with FreeBSD first. Regards, Ion

On Dec 23, 2008, at 8:21 AM, Ion Gaztañaga wrote:
Andy Wiese wrote:
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.
Andy,
I've just committed a fix in interprocess/detail/workaround.hpp to properly detect FreeBSD configuration. I've run all the tests in a FreeBSD 6 based DesktopBSD VmWare virtual machine. When you have time, just update that file and try to run tests.
I suspect NetBSD and OpenBSD will need similar tweaks, but let's start with FreeBSD first.
Regards,
Ion
Ion, Thanks so much! That totally fixes it. My test sets now run with identical results on OS-X and FreeBSD 7.0 (only two platforms I'm working on at the moment). I'm slightly disappointed in performance, but this is the first time I have used mmapped files heavily and I have barely begun to profile or optimize the code. I may be back asking some advice or opinions when I have a better grip on what is happening. Thank you for Christmas present, I hope you have a good holiday, Andy
participants (2)
-
Andy Wiese
-
Ion Gaztañaga