Change:
~"-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");

Discussion:
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)