We've noticed a spike in crash reports for Alamofire after the Xcode 11.4 / Swift 5.2 release (and our 5.1 release, but that's hopefully coincidence). They share a few common properties:
- Stack traces that don't end in Alamofire but the Swift runtime. Most commonly,
_swift_release_dealloc, but also
swift_checkMetadataState. (I'm also seeing the metadata crash on a client project.)
- Stack traces that don't match the user's code. Code shows in the stack that isn't being called, either explicitly by the user or by Alamofire itself.
- Some are fixed for some users when upgrading between Xcode 11.4 and 11.4.1, but not all, even for the same (apparent) crash.
None of these are replicable locally, as they likely rely on some confluence of project code and compiler version. Is anyone seeing anything similar? Any ideas on paths to investigate the issues?
@Jon_Shier sounds like they could be threading issues. Are all those folks running the same program under TSan (thread sanitizer) without any issues? Is the Alamofire test suite also TSan clean?
Alamofire 5 was built with the thread sanitizer from the beginning, as one of its primary goals was to fix a whole host of threading issues from the previous versions. It's been TSan clean for 2 years now. Even running thousands of iterations on the methods mentioned in the crashes doesn't turn up anything. Additionally, some of the crashes have methods in the stack trace the user never calls. I'll suggest they test with the sanitizer but some of them only replicate on device when signed certain ways, which is bizarre.
Spoke too soon and found a new one. I don't think it would have anything to do with the crashes, but... Also only shows up when a custom
requestQueue is used, and none of the cases which have posted code were doing that. It does seem that some combination of 5.1 and Xcode 11.4 hits something we can't otherwise reproduce.
We are seeing a similar thing with ReactiveSwift rather than AlamoFire. The crashes are all in swift_checkMetadataState, in a completely innocuous-looking piece of code. It seems this only happens on iOS 12.2 and below, which may be why you can't reproduce. On older iOS, it reproduces consistently every time for us.