Change:
A failed assertion inside a aborts on 10.9 with the following error: This appears to be due to the fact that libc++abi is different in 10.9 than in 10.8.
Current belief is that the taskinfo for is non-exported, which means a cannot be thrown across library boundaries. This is evidenced by the fact that says This worked on 10.8 due to bugs in the libc++abi that is used there. I don't know why this works on Linux.
After modifying to export , the failure still occurs, so there must be something else going on.
Does it work if you change the throw type to an int instead of a rust_task*?
No. Throwing an just gave me the error
Not going to be fixed for 0.7
mmm. OS X support for 10.9 seems important. Nominating for Maturity Milestone , Feature Complete.
Accepted for milestone 3, feature-complete
This appears to happen because OS X's libunwind is unable to unwind through due to it being unable to find a corresponding entry in the compact or DWARF unwind sections. This is due to the linker failing to preserve DWARF unwind info when passed on OS X 10.9.
Removing fixes this problem since the linker correctly preserves the compact unwind info from the object files when generating the final linked image. This flag was in to address a problem with the unwind information for , which is not compatible with the compact unwind format. It's not clear from that change how the problem manifests, but I didn't observe any problems after removing . It's possible that whatever problem that is working around is only an issue on prior versions of OS X.
And for sake of completeness, if removing is not an option then can be used to force the linker to preserve the DWARF unwind information. I wrote up rdar://problem/ about it not happening automatically when is specified since the current behavior on OS X 10.9 appears to be a bug.
wrote this: Is part of our segmented stack mechanism? (Which is currently disabled, and thus bugs injected into it would be masked/unobservable at the moment?)
I've since learnt that there's a specific pattern that can be emitted in the DWARF CIE or FDE that will inform the OS X linker it shouldn't attempt to convert the DWARF unwind information to its compact unwind format. The pattern the linker looks for is the return address register being saved twice to the same location. This looks like it should be easy to accommodate in , but I'm hesitant to submit a patch if I'm not able to test that path. Is there some way to test with the segmented stack mechanism enabled on OS X?
OS X 10.9 is probably going to come out in 2 days. This should be fixed now if possible.
Right now we don't have segmented stacks enabled, but we recently did indeed enable use of . if you have a patch I can see if we can unwind through locally, although I won't be running on 10.9 (I've got 10.8)

Discussion:
CFG_LIB_DSYM_GLOB_x86_64-apple-darwin=lib$(1)-*.dylib.dSYM CFG_GCCISH_CFLAGS_x86_64-apple-darwin := -Wall -Werror -g -fPIC -m64 -arch x86_64 CFG_GCCISH_CXXFLAGS_x86_64-apple-darwin := -fno-rtti <del> CFG_GCCISH_LINK_FLAGS_x86_64-apple-darwin := -dynamiclib -pthread  -framework CoreServices -Wl,-no_compact_unwind -m64 </del> <ins> CFG_GCCISH_LINK_FLAGS_x86_64-apple-darwin := -dynamiclib -pthread  -framework CoreServices -m64 </ins> CFG_GCCISH_DEF_FLAG_x86_64-apple-darwin := -Wl,-exported_symbols_list, CFG_GCCISH_PRE_LIB_FLAGS_x86_64-apple-darwin := CFG_GCCISH_POST_LIB_FLAGS_x86_64-apple-darwin :=

CFG_LIB_DSYM_GLOB_i686-apple-darwin=lib$(1)-*.dylib.dSYM CFG_GCCISH_CFLAGS_i686-apple-darwin := -Wall -Werror -g -fPIC -m32 -arch i386 CFG_GCCISH_CXXFLAGS_i686-apple-darwin := -fno-rtti <del> CFG_GCCISH_LINK_FLAGS_i686-apple-darwin := -dynamiclib -pthread  -framework CoreServices -Wl,-no_compact_unwind -m32 </del> <ins> CFG_GCCISH_LINK_FLAGS_i686-apple-darwin := -dynamiclib -pthread  -framework CoreServices -m32 </ins> CFG_GCCISH_DEF_FLAG_i686-apple-darwin := -Wl,-exported_symbols_list, CFG_GCCISH_PRE_LIB_FLAGS_i686-apple-darwin := CFG_GCCISH_POST_LIB_FLAGS_i686-apple-darwin :=

~"-Wl,-rpath,/usr/local/lib/gcc44"]); } <del> // OS X 10.6 introduced 'compact unwind info', which is produced by the // linker from the dwarf unwind info. Unfortunately, it does not seem to // understand how to unwind our __morestack frame, so we have to turn it // off. This has impacted some other projects like GHC. if sess.targ_cfg.os == session::OsMacos { args.push(~"-Wl,-no_compact_unwind"); } </del> // Stack growth requires statically linking a __morestack function args.push(~"-lmorestack");

is that OS X 10.6+ uses its own 'compact unwind info', an undocumented format generated by the linker from the DWARF CFI. This compact unwind info doesn't correctly <del> capture the nuance of the __morestack frame, and as a result all of our linking on OS X uses the -no_compact_unwind flag. </del> <ins> capture the nuance of the __morestack frame, so we need to prevent the linker from attempting to convert its DWARF unwind information. </ins> */ .text

// FIXME(#9854) these cfi directives don't work on windows. pushl %ebp <ins> #if defined(__APPLE__) // The pattern of the return address being saved twice to the same location // tells the OS X linker that it should not attempt to convert the DWARF // unwind information to the compact format. .cfi_offset %eip, -4 .cfi_offset %eip, -4 #endif </ins> // The CFA is 20 bytes above the register that it is // associated with for this frame (which will be %ebp) .cfi_def_cfa_offset 20

// bytes greater than a normal frame, to allow the unwinder // to skip the partial frame of the original function. .cfi_def_cfa_offset 24 <ins> #if defined(__APPLE__) // The pattern of the return address being saved twice to the same location // tells the OS X linker that it should not attempt to convert the DWARF // unwind information to the compact format. .cfi_offset %rip, -8 .cfi_offset %rip, -8 #endif </ins> // %rbp is -24 bytes from the CFA .cfi_offset %rbp, -24 movq %rsp, %rbp