i can’t speak for the bugs others have found, but the ones that i have found i have found on Linux, so i assumed they were compiler bugs, not runtime bugs. i had figured applications could avoid these bugs by simply not using the 5.5 release, are you saying all Swift applications running on the OS’s in question are now affected, regardless of toolchain?
I can at least confirm that the first issue is also occurring on my MacBook Air M1 running macOS 12 and using both Xcode 13 RELEASE as well as Xcode 13b5.
However, the stack corruption of your first example isn't close to 100% as you wrote in the SR, but more like in ~30% of the calls. Still an issue for apps using concurrency, though.
Haven't tried the other issues yet, though.
That is so much worse, however.
I don't know. Swift engineers who are working on fixing them will tell!
Thank you for testing this out on Linux and simplifying the code. I filed this SIMD segfault under:
One could argue them making Actors & stuff "latest OS only" meant that we couldn't risk our main codebases, even in a branch, yet.
Perhaps most of us didn't actually try the feature in our codebases as a result. So they didn't get alot of real testing from all of us.
Just a thought. I am very excited about the feature, and hope to roll out using it next year.
There is a lot of unhelpful hyperbole here in this thread. Bugs happen, even in compilers, and regardless of how long a feature has been in production you will still eventually be shocked to find that there's a carefully-crafted 5-line program that triggers a problem. I completely understand that when a compiler bug hits your code it's an unwelcome surprise that can be very, very hard to debug and work around. However, the tone of this conversation is actively harmful and reflects very poorly on this community.
We greatly appreciate the bug reports provided here by @taylorswift, which have helped us track down a previously-unknown miscompile with asynchronous calls. We have a fix that addresses all of the bugs reported at the beginning of this thread, and we'll look to roll it out as soon as it is feasible.
For some background, the problem itself is an unsafe coroutine optimization in the formation of asynchronous stack frames. The optimization seeks to reduce the size of asynchronous stack frames by evaluating when the lifetime of a value has ended before a next suspension point, in which case that value can be stored on the synchronous stack only and need not be preserved across the suspension point---which reduces overall heap usage (asynchronous stack frames go on the heap). This optimization failed to account for some kinds of control flow, so it would effectively optimize away live values, resulting in the observed asynchronous stack corruption bugs. The actual bug appears to have been introduced in July 2020 in LLVM's coroutine handling, so it's gone undiagnosed for more than a year despite LLVM coroutines being in use for a number of different features (e.g., C++20 coroutines in Clang, async functions in Swift). In the short term, we're disabling the optimization, at the cost of slightly larger asynchronous stack frames. Longer term, the optimization needs to be made sound because minimizing the size of the asynchronous stack is part of the overall performance storage for asynchronous code.
If it is fixed in version 5.5.1, will it affect performance?
Hello Doug, one quick followup to your welcomed and very detailed explanation. Will this require iOS 15.1 as minimum SDK target or is it something that can be fixed in a compiler / Xcode update only?
this is incredible news! kudos to the compiler team for the fast turnaround once these issues were brought to light.
i apologize for my part in contributing to the excessively heated rhetoric in this thread. and having been told of the spillover on twitter from thursday, i completely agree that the discourse there devolved into a lot of unhelpful dunking. at the same time, i don’t really think it’s necessary to go back and downplay or minimize the issues people faced in the beginning, especially now that we have a fix on hand.
i for one, would rather have slow, but correct code, than fast but buggy code.
Let's be careful here- we know this particular bug escaped into the wilds - and we know that async await is new, and that means there aren't alot of codebases available to test it. Lets get these fixes into Xcode betas and iterate. Given the scope of this work, and the speed with which it caused problems in the wild, there are probably more bugs hiding behind this one.
And all of us who can in the community, try it out and test.
It's a compiler-only change with no impact on any OS.
hi, i just tested with the Oct 5 nightly snapshot, which is the first since that PR was merged, and the issues are still present. the commit hashes are
$ swiftc --version Swift version 5.6-dev (LLVM 7aef0efea99e2c6, Swift e4f71c8e118fc09) Target: x86_64-unknown-linux-gnu
i’m not sure if the LLVM hash
7aef0efea99e2c6 is before or after the fix was merged
This snapshot did not have the fix.
okay! thanks for clarifying!
Tested on M1 with Xcode 13/ iOS 15 with below Swift 5.5 version seems doesn't hit the 1st issue
swift-driver version: 1.26.9 Apple Swift version 5.5 (swiftlang-1300.0.31.1 clang-1300.0.29.1)
hi, i’ve successfully built an updated toolchain against llvm
stable/20210726, and i can confirm that 3 out of 4 of the bugs listed in the beginning of this thread are no longer present.
i’ve gone ahead and closed those three issues on the bug tracker.
i do not know if the bugs discovered by @mickeyl are still present.
Good news! Do you perhaps have webspace to upload the toolchain somewhere? I'd like to verify my issues.
what platform are you on? i only have binaries for Ubuntu 20.04
I'd appreciate Ubuntu 20.04 binaries... any chance you can push a docker image to docker hub? (May not be a huge deal... I assume
swiftlang/swift:nightly-focal-main won't be stuck at 10-5 forever...)