Boost logo

Boost :

Subject: Re: [boost] [fiber] Mac OS X
From: Edd Dawson (lists_at_[hidden])
Date: 2011-01-30 10:19:11

On 1/29/2011 3:22 AM, Daniel Larimer wrote:

> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000010fa0
> 0x00007fff80820f89 in makecontext ()
> (gdb) bt
> #0 0x00007fff80820f89 in makecontext ()
> #1 0x000000010001f3a3 in boost::contexts::context::impl_t::impl_t (this=0x100100210, fn=0x100016990<boost::fibers::detail::trampoline(void*)>, vp=0x100100190, stacksize=65536, nxt=0x1001001c0, alloc_=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:58
> #2 0x000000010001f183 in ~auto_ptr [inlined] () at /usr/include/c++/4.2.1/memory:59
> #3 0x000000010001f183 in boost::contexts::context::init_ (fn=0x100016990<boost::fibers::detail::trampoline(void*)>, nxt=0x1001001a0, vp=0x100100190, stacksize=65536, alloc=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:77
> #4 0x00000001000017db in boost::contexts::context::create<boost::contexts::protected_stack_allocator> ()
> #5 0x0000000100001a96 in boost::fibers::detail::fiber_base::fiber_base<boost::contexts::protected_stack_allocator> ()
> #6 0x0000000100001b65 in boost::fibers::detail::fiber_object<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0> >::fiber_object<boost::contexts::protected_stack_allocator> ()
> #7 0x0000000100001bdd in boost::fibers::fiber::make_fiber_<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> ()
> #8 0x0000000100001c54 in boost::fibers::fiber::fiber<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> ()
> #9 0x00000001000010be in main ()

On OS X, it certainly used to be the case that you had to define _XOPEN_SOURCE
before including <ucontext.h>. I notice that context_ucontext.cpp doesn't do
this. When I bumped in to this in 2008 [1], it was already a known issue, but I
don't know if Apple has fixed it already.

I'd also suggest considering changing the default stack size to SIGSTKSZ rather
than using an arbitrary(?) value of 65536. From the POSIX spec [2]:

"The value SIGSTKSZ is a system default specifying the number of bytes that
would be used to cover the usual case when manually allocating an alternate
stack area."

Kind regards,



Boost list run by bdawes at, gregod at, cpdaniel at, john at