Skip to content

Runtime: Bridging an Error to NSError requires only checking its domain. #7983

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 9, 2017

Conversation

jckarter
Copy link
Contributor

@jckarter jckarter commented Mar 8, 2017

The lazy population of the NSError fields is ordered such that the domain is written into the object last with acq/rel ordering, so another thread only needs to check the domain to see whether the initialization has already happened. (The initialization itself is idempotent, so we can optimistically perform the initialization and discard the results if we race.) Checking the user info is redundant, and is also wrong for real NSError objects, since [NSError errorWithDomain:d code:c userInfo:nil] will in fact plant nil in the userInfo field of the object, leading us to attempt to bridge an already-native NSError.

The lazy population of the NSError fields is ordered such that the domain is written into the object last with acq/rel ordering, so another thread only needs to check the domain to see whether the initialization has already happened. (The initialization itself is idempotent, so we can optimistically perform the initialization and discard the results if we race.) Checking the user info is redundant, and is also wrong for real NSError objects, since [NSError errorWithDomain:d code:c userInfo:nil] will in fact plant nil in the userInfo field of the object, leading us to attempt to bridge an already-native NSError.
@jckarter
Copy link
Contributor Author

jckarter commented Mar 8, 2017

@swift-ci Please test

@jckarter
Copy link
Contributor Author

jckarter commented Mar 8, 2017

@swift-ci Please TSan test

@jckarter
Copy link
Contributor Author

jckarter commented Mar 8, 2017

@swift-ci Please test OS X

… expects.

The ABI mismatch here would cause a crash in cases when the Foundation overlay wasn't available, or its implementation of swift_Foundation_getErrorDefaultUserInfo wasn't dynamically resolvable, such as in a stripped statically linked binary. Fixes rdar://problem/29173132.
@swift-ci
Copy link
Contributor

swift-ci commented Mar 8, 2017

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 0ec27bd
Test requested by - @jckarter

@jckarter
Copy link
Contributor Author

jckarter commented Mar 9, 2017

@swift-ci Please test OS X

@jckarter
Copy link
Contributor Author

jckarter commented Mar 9, 2017

@swift-ci Please test

@swift-ci
Copy link
Contributor

swift-ci commented Mar 9, 2017

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 0ec27bd
Test requested by - @jckarter

@swift-ci
Copy link
Contributor

swift-ci commented Mar 9, 2017

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 0ec27bd
Test requested by - @jckarter

@jckarter
Copy link
Contributor Author

jckarter commented Mar 9, 2017

@swift-ci Please test OS X

@jckarter jckarter merged commit 7e3e7c0 into swiftlang:master Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants