Repository navigation
Task failure aborts app on OS X 10.9 #6849
Description
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.
Activity
lilyball commentedon Jun 27, 2013
Current belief is that the task_info for
rust_task*is non-exported, which means arust_task*cannot be thrown across library boundaries. This is evidenced by the fact thatnm librustrt.dylibsaysThis 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 commentedon Jun 27, 2013
After modifying rustrt.def.in to export
_ZTIP9rust_task, the failure still occurs, so there must be something else going on.brson commentedon Jun 28, 2013
@kballard Does it work if you change the throw type to an int instead of a rust_task*?
lilyball commentedon Jun 28, 2013
@brson No. Throwing an
intptr_tjust gave me the errorbrson commentedon Jul 3, 2013
Not going to be fixed for 0.7
pnkfelix commentedon Aug 23, 2013
mmm. OS X support for 10.9 seems important. Nominating for Maturity Milestone #3, Feature Complete.
catamorphism commentedon Aug 29, 2013
Accepted for milestone 3, feature-complete
bdash commentedon Sep 27, 2013
This appears to happen because OS X's libunwind is unable to unwind through
rust_begin_unwinddue 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_unwindon OS X 10.9.bdash commentedon Sep 27, 2013
Removing
-no_compact_unwindfixes 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 commentedon Sep 28, 2013
And for sake of completeness, if removing
-no_compact_unwindis not an option then-keep_dwarf_unwindcan 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_unwindis specified since the current behavior on OS X 10.9 appears to be a bug.pnkfelix commentedon Sep 28, 2013
@bdash wrote this:
Is
__morestackpart of our segmented stack mechanism? (Which is currently disabled, and thus bugs injected into it would be masked/unobservable at the moment?)bdash commentedon Oct 19, 2013
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 commentedon Oct 20, 2013
OS X 10.9 is probably going to come out in 2 days. This should be fixed now if possible.
alexcrichton commentedon Oct 21, 2013
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__morestacklocally, although I won't be running on 10.9 (I've got 10.8)auto merge of #10013 : bdash/rust/mavericks-unwinding, r=alexcrichton
Auto merge of rust-lang#6849 - flip1995:dogfood-fix, r=matthiaskrgr