Guard against racy access to NSError.setUserInfoValueProvider. #4558
Conversation
…lang#4280) This API is documented in its headers to only allow being called once for a particular domain, so we have to make sure our check for an existing provider is synchronized with the setting. rdar://problem/27541751 (cherry picked from commit af1a815)
|
@swift-ci Please test OS X platform |
|
Several tests are crashing in error-related code after this change. This might only affect un-optimized builds. |
|
Aargh. That doesn't make any sense. Thanks, Greg. |
|
sigh It's a known issue, rdar://problem/27226313. @slavapestov, were you planning to do anything here? |
|
It does only affect builds with unoptimized overlays, by the way. |
|
Beyond cherry-picking for the swift 3.0 branch, I wasn't planning on working on SILGen support for factory initializers soon. But if we keep hitting this again and again it might be worth addressing properly. |
|
What was the cherry-pick? Disabling tests, or actually fixing the issue? Or at least papering over it? (@zisko is also concerned about leaving a bot red, so if that cherry-pick isn't going to fix it I'll disable these tests on unoptimized stdlib configurations.) |
[pull] swiftwasm from main
userInfodictionary without having to actually construct a dictionary in Swift. However, this API can only be called once for a particular domain, so we have to make sure our check for an existing provider is synchronized with the setting. Otherwise, we get a race condition that could lead to an over-release.