Crash with Incorrect actor executor assumption

Question

Created Oct ’24

Replies 2

Boosts 0

Views 1.4k

Participants 2

I'm seeing a crash compiling with Swift 6 that I can reproduce with the following code.

It crashes with "Incorrect actor executor assumption". Is there something that the compiler should be warning about so that this isn't a runtime crash?

Note - if I use a for in loop instead of the .forEach closure, the crash does not happen.

Is the compiler somehow inferring the wrong isolation domain for the closure?

import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .task {
                _ = try? await MyActor(store: MyStore())
            }
    }
}

actor MyActor {
    var credentials = [String]()
    
    init(store: MyStore) async throws {
        try await store.persisted.forEach {
            credentials.append($0)
        }
    }
}

final class MyStore: Sendable {
    var persisted: [String] {
        get async throws {
            return ["abc"]
        }
    }
}

The stack trace is:

* thread #6, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = signal SIGABRT
    frame #0: 0x0000000101988f30 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000100e2f124 libsystem_pthread.dylib`pthread_kill + 256
    frame #2: 0x000000018016c4ec libsystem_c.dylib`abort + 104
    frame #3: 0x00000002444c944c libswift_Concurrency.dylib`swift::swift_Concurrency_fatalErrorv(unsigned int, char const*, char*) + 28
    frame #4: 0x00000002444c9468 libswift_Concurrency.dylib`swift::swift_Concurrency_fatalError(unsigned int, char const*, ...) + 28
    frame #5: 0x00000002444c90e0 libswift_Concurrency.dylib`swift_task_checkIsolated + 152
    frame #6: 0x00000002444c63e0 libswift_Concurrency.dylib`swift_task_isCurrentExecutorImpl(swift::SerialExecutorRef) + 284
    frame #7: 0x0000000100d58944 IncorrectActorExecutorAssumption.debug.dylib`closure #1 in MyActor.init($0="abc") at <stdin>:0
    frame #8: 0x0000000100d58b94 IncorrectActorExecutorAssumption.debug.dylib`partial apply for closure #1 in MyActor.init(store:) at <compiler-generated>:0
    frame #9: 0x00000001947f8c80 libswiftCore.dylib`Swift.Sequence.forEach((τ_0_0.Element) throws -> ()) throws -> () + 428
  * frame #10: 0x0000000100d58748 IncorrectActorExecutorAssumption.debug.dylib`MyActor.init(store=0x0000600000010ba0) at ContentView.swift:27:35
    frame #11: 0x0000000100d57734 IncorrectActorExecutorAssumption.debug.dylib`closure #1 in ContentView.body.getter at ContentView.swift:14:32
    frame #12: 0x0000000100d57734 IncorrectActorExecutorAssumption.debug.dylib`closure #1 in ContentView.body.getter at ContentView.swift:14:32
    frame #13: 0x00000001d1817138 SwiftUI`(1) await resume partial function for partial apply forwarder for closure #1 () async -> () in closure #1 (inout Swift.TaskGroup<()>) async -> () in closure #1 () async -> () in SwiftUI.AppDelegate.application(_: __C.UIApplication, handleEventsForBackgroundURLSession: Swift.String, completionHandler: () -> ()) -> ()
    frame #14: 0x00000001d17b1e48 SwiftUI`(1) await resume partial function for dispatch thunk of static SwiftUI.PreviewModifier.makeSharedContext() async throws -> τ_0_0.Context
    frame #15: 0x00000001d19c10c0 SwiftUI`(1) await resume partial function for generic specialization <()> of reabstraction thunk helper <τ_0_0 where τ_0_0: Swift.Sendable> from @escaping @isolated(any) @callee_guaranteed @async () -> (@out τ_0_0) to @escaping @callee_guaranteed @async () -> (@out τ_0_0, @error @owned Swift.Error)
    frame #16: 0x00000001d17b1e48 SwiftUI`(1) await resume partial function for dispatch thunk of static SwiftUI.PreviewModifier.makeSharedContext() async throws -> τ_0_0.Context

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’24

Accepted Answer

Recommended

Weirdly, I don’t see this trap, but I do get a runtime issue:

    try await store.persisted.forEach {
 // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 //  warning: data race detected: actor-isolated function at … was not called on the same actor

I’m able to avoid that by rewrite the code like this:

actor MyActor {
    let store: MyStore
    var credentials = [String]()
    
    init(store: MyStore) async throws {
        self.store = store
        try await self.test()
    }
    
    func test() async throws {
        try await store.persisted.forEach {
            credentials.append($0)
        }
    }
}

I think this issue relates to the fact that you’re doing this in an initialiser. Initialises have two phases: pre and post complete initialisation. After complete initialisation the actor is fully up and running, and thus you can do things like call async methods. Before initialisation the actor is kinda in a bit of a limbo state. For example, if you reversed the two lines in my initialiser above, the compiler complains that Variable 'self.store' used before being initialized, which makes perfect sense.

I think what’s happening in your case is that the compiler hasn’t realised that the actor is fully initialised and thus it’s applying its pre-initialisation checks. However, the actor is fully initialised, and so you’re expecting it to apply its post-initialisation checks.

I’m able to avoid this problem by moving the call off to an async method. Calling that in the initialiser convinces the compiler to use its post-initialisation checks.

Still, I’m not a compiler engineer, so my rationale is largely speculative. However, the path forward is clear: It would be nice if the compiler either did the right thing here or issued a compile-time error. Discovering this at runtime isn’t any fun. I encourage you to file a bug against Swift itself with this example.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

rolson OP

Oct ’24

Thanks Quinn. I can also work around the bug by using for in instead of .forEach:

    ...
    init(store: MyStore) async throws {
        for persisted in try await store.persisted {
            credentials.append(persisted)
        }
    }

So I think it has something to do with Actor inference in the .forEach closure.

I filed a bug with Swift: https://github.com/swiftlang/swift/issues/76804

0