Looks like a real race. It seems irrelevant whether it's run under Swift 3.2 or Swift 4 mode, but TSan only detects the issue sometimes. Most likely that's either because:
1) the order of the async callbacks (via DispatchQueue.utility.async, etc.) can be "okay" in some program runs, or
2) the racy accesses just happen to be done on the same thread (even when they're on different queues).
In any case, the SessionManager.retry method seems to be modifying the request and that's not synchronized with the main thread using the request. Again, looks like a real race that needs fixing.
On 2 Jul 2017, at 16:53, Jon Shier <email@example.com> wrote:
Investigating this now more thoroughly and it appears my initial concern was wrong, as it’s detected the threading issues in Swift 3.2 mode as well. I’m not sure whether this was an Xcode 9b1 issue, a product of switching the Swift version back and forth while make Alamofire compatible with Swift 3.2 and 4 or what, but the issue does appear now in both 3.2 and 4. I’m tracking the issue in https://github.com/Alamofire/Alamofire/issues/2189 but it seems to be a legit issue. Thanks!
On Jun 26, 2017, at 1:54 PM, Joe Groff <firstname.lastname@example.org <mailto:email@example.com>> wrote:
On Jun 26, 2017, at 10:33 AM, Joe Groff via swift-users <firstname.lastname@example.org <mailto:email@example.com>> wrote:
On Jun 25, 2017, at 3:56 PM, Jon Shier via swift-users <firstname.lastname@example.org <mailto:email@example.com>> wrote:
Running Alamofire through the thread sanitizer and the thread sanitizer finds issues in Swift 4 mode but not Swift 3.2. Does Swift 4 add additional threading instrumentation that you don’t get under other versions? Or is there some other runtime difference that explains it?
Would you be able to file bugs for specific issues so we can investigate whether the behavior changes are intentional?
cc'ing Anna, Devin, and Kuba who worked on improving TSan support for Swift.