Memory corruption due to Swift concurrency when deploying on iOS 15 and below

PoltoraIvana · February 7, 2023, 10:25am

When we tried to migrate to Xcode 14 we bumped into serious problems with memory corruption. After thorough investigation, we found out that concurrency lib when back-deployed (to iOS 15 and below) corrupts heap.
We have opened an issue for that:

github.com/apple/swift

XCode 14.2/Swift 5.7 memory corruption on Task creation when app is launched on iOS < 16.

opened 11:07PM - 03 Feb 23 UTC

mstyura

bug triage needed

**Description** Task creation in some contexts can lead to corruption of the application's memory. Examples can be seen in the demo application code. **Steps to reproduce** 1. Download demo application source code: https://github.com/mstyura/Swift-Task-Heap-Curruption-on-iOS-15-and-earlier. 2. Select scheme `TaskCrasher - Release - libgmalloc - use with arm64 simulator`; 3. Run demo app on `arm64` iOS simulator with `iOS 15.4`; **Expected behavior** Application is not crashed. **Actual behavior** Demo app crashes with `libgmalloc` enabled. Address sanitizer unfortunately unable to catch the issue. ![выява](https://user-images.githubusercontent.com/385639/216724508-ed07a8e7-41c4-4934-a483-a020738d5b06.png) I've actually encountered problem on real production application on iOS device where app is randomly crashed on memory access to address `0x100000000 + offset` where offset is usually `+0x10`,` +0x20` or `-0x8` in application or system library code. Also in real application `libmalloc` were capable to detect it was corrupted on some point, but it was unclear who was responsible for corruption. **Environment** - Swift compiler version info ``` swift-driver version: 1.62.15 Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51) Target: arm64-apple-macosx13.0 ``` - Xcode version info ``` Xcode 14.2 Build version 14C18 ``` - Deployment target: checked that issue happen on iOS 14 and iOS 13 and iOS 15 as deployment target. Additional context: An app that I observed crashing worked fine when built with `XCode 13.4.1` and `Swift 5.6`, but experienced significant, random crashes with "bad access" errors on addresses like `0x100000020` when built with `XCode 14.2` or` XCode 14.1` and `Swift 5.7`. As a result, it's currently not feasible to target iOS versions lower than 16 and use `Swift 5.7` with async functions and Tasks without encountering random crashes. **UPD**: On demo application issue is only happen when compiled with `-O` (optimize for speed), but not when compiled with `-Osize` (optimize for size) or `-Onone`.

IMO it looks very serious. Can anybody from the Swift team tell if they are aware of this?
@Douglas_Gregor @John_McCall

DevAndArtist · February 7, 2023, 10:40am

I'm curious on what's going on here as well.

As a result, it's currently not feasible to target iOS versions lower than 16 and use Swift 5.7 with async functions and Tasks without encountering random crashes.

That's a scary claim.

We're currently developing a feature that requires Concurrency and is targeting iOS 15. One day, out the blue the application started crashing. The crash was reproducible and always at the same place. However that seemed totally random to me. I spent hours trying enabling some Core Data flags to gather a bit more data, but I ended up giving up on that. One day later, the rebuilt project just started working again. It almost smelled like some Xcode cache was cleaned up over night. (I didn't try to clean-build the project when I was facing the crashes.)

Unfortunately I cannot provide any reproducible code as the issue magically disappeared.

PoltoraIvana · February 7, 2023, 10:50am

In the end we managed to reduce to a sample project.
There are some workarounds (-Osize instead of -Ospeed, for example), but they seem sub-optimal.

John_McCall · February 8, 2023, 9:34pm

We're tracking a fix to this problem now; hopefully we can get it done soon.