
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

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

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