Adding a CompactedCollection to an Array triggers EXC_BAD_ACCESS #209
Comments
natecook1000
added
bug
|
Thanks for reporting this, @davbeck! Verified in Swift 5.9 – will investigate further. |
|
Hi, I saw the "help wanted" tag on this and have been investigating. Hope I haven't duplicated anyone's efforts. Here's what I've learned so far. My own SwiftUI iOS test app Xcode project has similar code to the example above: struct ContentView: View {
let things = [Thing()].compacted() + [Thing()]
var body: some View {
let _ = print(Unmanaged.passUnretained(things[0]).toOpaque())
VStack {
Text(things.description)
}
.padding()
}
}and crashes with this stack trace when built using Release configuration in Xcode 15.1: Why the crash occurs[This Swift stdlib and ObjC code is new to me, so let me know if I've gotten any of the details wrong.] The proximate cause of the crash is that the first The first Corruption mechanism still unknownI tried to determine when the isa pointer gets set to I then tried to identify the Swift commit that caused this issue by doing a binary search through the in a directory containing a very simple Swift package with an executable target that does let twoNewThings = [Thing()].compacted() + [Thing()]
print(twoNewThings.description)Issue might involve Swift Package ManagerMy results were confusingly inconsistent until I realized that the toolchain used to compile didn't matter (as long as it was built from the commits I tried on This doesn't crash but this does even though the custom-built toolchain specified by
Next stepsI compared the logs from builds of my iOS test project in Xcode 14.3.1 vs. 15.1, and noted that for Xcode 15.1 the command line used to compile the Algorithms module has several extra switches so I'd like to see if any of these could be the cause of the problem. I'd also like to repeat my binary search through the Swift 5.9 development tags, now that I know how to get reliable results from my test. And I'd like to study the implementation of |
|
I've been working with a more minimal reproducible case which eliminates SPM. It's this command-line macOS program compiled with Compacted.swift copied from swift-algorithms. Using Xcode 15.2 Beta released on 2023-12-12 building without optimization produces a binary that doesn't crash But building with The stack trace shows it's the same crash as with my iOS test case The crash can also be reproduced using the toolchains and macOS SDKs from various other Xcode 15 releases I've tried, including Xcode 15.0 Beta, Xcode 15.0.1, and Xcode 15.1. It can't be reproduced with Xcode 14.3.1 or Xcode 14.2, even with So I can confirm the issue is caused by I'm still working on narrowing down the range of commits that may have introduced the problem, but I haven't yet built a custom toolchain that reproduces the crash using the above test case. I've tried various |
|
I found a set of
Using that with the test case mentioned above, I find that the issue seems to have been introduced between According to the output from I'm guessing the most fruitful projects to investigate are llvm-project and swift. I might also try to narrow the commit range further between the two snapshot tags. |
|
After testing main branch commits between My testing strategy was to checkout the desired main branch commit in the swift project, then run then build with Here are the results for 004d0b1 and the commit immediately preceding it on main, 77527c9: The I also built a toolchain identical to the one that reproduces the issue, except with alias analysis disabled (if I'm understanding the code, which is definitely not guaranteed 😄) by the following diff That toolchain did not reproduce the issue, so I'm focusing further investigation on the new alias analysis. Unfortunately, it's still the case that when I step through the instructions of a crashing binary from the beginning of |
|
@davbeck / @toddthomas – thanks for your work looking into this! It looks like there were some overreleases fixed in 5.10. Could I ask you to verify that your test cases work correctly with a 5.10 or later compiler? I'm seeing my reproducer fixed on the latest toolchain ( |
|
I still get the crash using a toolchain built from the latest tag I see on As with my previous testing, I only get the crash when the test case is compiled with No crash with no optimization, no crash with only I'll try latest |
|
A toolchain built from the most recent tag on (where |
|
On |
|
Commit d93e65d, the merge of PR 70710, is the fix. I don't see the diff in lib/SILOptimizer/Utils/Generics.cpp from that commit on |
|
There's something important in the command used to build the toolchain. If I use a build command that's basically the one from the getting started guide, with options added to install the toolchain: then regardless of what commit I build from, the resulting toolchain doesn't build a test binary that reproduces this issue. But if I use a toolchain build command I simplified a bit from what I see in logs on ci.swift.org: then the resulting toolchain, when built from commits in the range [004d0b1, 86d9e2c], can build crashing test binaries. I haven't narrowed down the exact combination of toolchain build command options necessary to demonstrate this issue. These clean builds are time consuming. 😅 |
|
@natecook1000 I noticed Xcode 15.3 Beta has a Swift 5.10 toolchain, so I built my test case with it, which crashed. That aligns with what I've seen with the toolchains I've built myself. The fix is on |
|
@natecook1000 fixed in Xcode 16.0.0 Beta w/ Swift 6 |
When combining a CompactedCollection of objects with an array of objects, in release mode, code will crash with EXC_BAD_ACCESS.
Swift Algorithms version:
1.1.0but I also saw this in0.0.3Swift version:
swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)
Target: arm64-apple-macosx14.0
Checklist
mainbranch of this packageSteps to Reproduce
I've attached an iOS project that reproduces this. From the Xcode template, I've edited the scheme to run in Release mode. Here is the relevant code that triggers the crash:
Expected behavior
Not to crash
Actual behavior
EXC_BAD_ACCESS
The text was updated successfully, but these errors were encountered: