Task failure aborts app on OS X 10.9

[lilyball]

A failed assertion inside a task::try aborts on 10.9 with the following error:

libc++abi.dylib: terminating with uncaught exception of type rust_task*
fish: Job 1, './myprog' terminated by signal SIGABRT (Abort)

This appears to be due to the fact that libc++abi is different in 10.9 than in 10.8.

[lilyball]

Current belief is that the task_info for rust_task* is non-exported, which means a rust_task* cannot be thrown across library boundaries. This is evidenced by the fact that nm librustrt.dylib says

0000000000033940 d __ZTIP9rust_task

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.

[lilyball]

After modifying rustrt.def.in to export _ZTIP9rust_task, the failure still occurs, so there must be something else going on.

[brson]

@kballard Does it work if you change the throw type to an int instead of a rust_task*?

[lilyball]

@brson No. Throwing an intptr_t just gave me the error

libc++abi.dylib: terminating with uncaught exception of type long

[brson]

Not going to be fixed for 0.7

[pnkfelix]

mmm. OS X support for 10.9 seems important. Nominating for Maturity Milestone #3, Feature Complete.

[catamorphism]

Accepted for milestone 3, feature-complete

[bdash]

This appears to happen because OS X's libunwind is unable to unwind through rust_begin_unwind 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 -no_compact_unwind on OS X 10.9.

[bdash]

Removing -no_compact_unwind 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 added in cb5f636 to address a problem with the unwind information for __morestack, 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 -no_compact_unwind. It's possible that whatever problem that is working around is only an issue on prior versions of OS X.

[bdash]

And for sake of completeness, if removing -no_compact_unwind is not an option then -keep_dwarf_unwind can be used to force the linker to preserve the DWARF unwind information. I wrote up rdar://problem/15096695 about it not happening automatically when -no_compact_unwind is specified since the current behavior on OS X 10.9 appears to be a bug.

[pnkfelix]

@bdash wrote this:

It's not clear from that change how the problem manifests, but I didn't observe any problems after removing -no_compact_unwind

Is __morestack part of our segmented stack mechanism? (Which is currently disabled, and thus bugs injected into it would be masked/unobservable at the moment?)

[bdash]

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 __morestack, 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?

[lilyball]

OS X 10.9 is probably going to come out in 2 days. This should be fixed now if possible.

[alexcrichton]

Right now we don't have segmented stacks enabled, but we recently did indeed enable use of __morestack. @bdash, if you have a patch I can see if we can unwind through __morestack locally, although I won't be running on 10.9 (I've got 10.8)