5.10 "LoadableByAddress" non-deterministic compiler crash when parameter pack closure saved to instance property. #74609
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
compiler
The Swift compiler itself
crash
Bug: A crash, i.e., an abnormal termination of software
function types
Feature → types: function types
generics
Feature: generic declarations and types
good first issue
Good for newcomers
IRGen
LLVM IR generation
needs tests
Flag: Issue is fixed but needs tests / PR needs tests
parameter packs
Feature → generics: Parameter packs
properties
Feature: properties
swift 5.10
types
Feature: types
Comments
vanvoorden
added
bug
|
@AnthonyLatsis Would you know if we were tracking anything related to this? This crash seems to be fixed in 6.0… but I don't know if someone landed a fix to this issue directly or this fix came along implicitly with a fix for a different issue. Were there any related 5.10 workarounds to another issue that might workaround this one before 6.0 ships? Thanks! |
|
@slavapestov Do you remember if we were tracking anything similar to this in 5.10? Do you know if we documented any workarounds to compile that code from 5.10? Thanks! |
hborla
added
parameter packs
AnthonyLatsis
added
compiler
I could not find anything similar enough. It seems so — I cannot get it to crash either. As for workarounds, indirection does the job, as it often does: private struct FnBox<T> {
let fn: () -> T
}
struct Repeater<each Element> {
private let _elements: (repeat FnBox<each Element>)
var elements: (repeat () -> each Element) {
return (repeat (each _elements).fn)
}
init(elements element: repeat @escaping () -> each Element) {
self._elements = (repeat FnBox(fn: each element))
}
func printElements() {
print((repeat (each elements)()))
}
}
let repeater = Repeater(elements: { 2 }, { "" }, { true })
repeater.printElements() |
|
Dear first-time contributors, this only needs an IRGen test case. Here is a minimal crash reproduction for Swift 5.10: struct Foo<each T> {
let tuple: (repeat () -> each T)
}
func test(_: Foo<Int>) {} // Boom
// func test(_: Foo<Int, Int>) {} // No boom |
@AnthonyLatsis Hmm… I was unable to repro the crash with this example from |
Ahh… it looks like this works for me for 5.10 and unblocks my original use-case. Thanks! |
I confirmed the crash with the godbolt.org 5.10 compiler. Does it reproduce in your terminal? Try echo 'struct Foo<each T> {let tuple: (repeat () -> each T)};func test(_: Foo<Int>) {}' | swiftc -emit-ir -where |
https://gist.github.com/vanvoorden/aa279eb43920870f70dac07343c5fcc2 Hmm… I tried this locally and don't see a crash in here. Godbolt looks like it is running on Intel. I am running on Apple Silicon. Would that have something to do with it? |
Ok, this is starting to make more sense. A Since neither yours nor the Godbolt 5.10 compilers hit an assertion, they must be no-asserts compilers. Without this assertion to terminate the program we get a memory access violation, which appears to not be deterministically caught by Apple Silicon in contrast to |
|
@AnthonyLatsis For some reason this workaround seems to lead to some |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
https://forums.swift.org/t/non-deterministic-5-10-compiler-failures-from-predictablememoryaccessoptimizations-and-swift-5-10/72630
This is a repro for a
PredictableMemoryAccessOptimizationscrash I originally saw in another project. There's a lot going on in that project… I attempted to look for a more "clean" repro. This is now reporting as aLoadableByAddresscrash… but the code is following a similar pattern to my other project.This crash seems to be non-deterministic… sometimes it crashes… sometimes it doesn't.
This code does not (for now) crash for me from the 6.0 toolchain. I'm only seeing the crashes from production Swift 5.10 (and Xcode 15.4).
It looks like this will be fixed once 6.0 goes live in Q3. I would really like to find some kind of workaround that could unblock me when building from production Xcode 15.4. Any ideas for that would be great!
Reproduction
This code does not crash with probability one. I can clean and build again and I eventually see a crash.
Saving the parameter pack elements as the return values of a closure pack seems to be important to the crash. It also seems to be important for the repeating element type to be a generic type.
I can prevent the crash with probability one by not saving the closure pack to a variable:
Stack dump
Environment
swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: arm64-apple-macosx14.0
The text was updated successfully, but these errors were encountered: