Crash with Progress type, Swift 6, iOS 18

It’s hard to say exactly what’s going on here, but the immediate cause of the crash is a trap inserted by the compiler to ensure correct concurrent data isolation. I posted an in-depth analysis of a similar issue here. Read that before reading the rest of my reply.

In the code snippet you posted from the MyController type in frame 3 of your backtrace? Is that main actor isolated? Or an actor?

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

MyController is a simple class not bound to any actor. The init code is above, it is also not bound to any actor.

I tried binding the init to the MainActor, that didn't help.

I also tried making the closures passed into progress @Sendable and that did not fix it, which surprised me.

I’m not sure what’s going on here. I tried to create a small test project to see if I could reproduce it, but that didn’t work (my failed attempt is below, just FYI).

Can you flesh this out into a test project that reproduces the problem?

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

class MyController {
    init() {
        progress = Progress()
        progress.kind = .file
        progress.fileOperationKind = .downloading
        
        progress.pausingHandler = { [weak self] in
            self?.setIsPaused(true)
        }
        
        progress.resumingHandler = { [weak self] in
            self?.setIsPaused(false)
        }
        
        progress.cancellationHandler = { [weak self] in
            self?.cancel()
        }
    }

    let progress: Progress

    private func setIsPaused(_ newValue: Bool) {
    }

    private func cancel() {
    }
}

struct ContentView: View {
    @State var controllerQ: MyController? = nil
    var body: some View {
        VStack {
            Button("Start") {
                guard self.controllerQ == nil else { return }
                print("will start")
                self.controllerQ = .init()
            }
            Button("Cancel") {
                guard let controller = self.controllerQ else { return }
                print("will cancel")
                controller.progress.cancel()
            }
        }
        .padding()
    }
}

I've got the same basic project that I extracted to try to get a reproducer. I also setup unit tests with both Swift Testing and XCTest (we mostly see this issue in our test environment). Unfortunately, I have not been able to reproduce it outside of our codebase.

Our code is in a Swift Package, so one thing that I haven't tried is breaking out this reproducible code into a package and making that package a dependency of an app. There is no practical difference I can identify between the code we have tried to reproduce the crash and our production code.

Within our production codebase, I can reproduce with this simple class:

public final class MyController {
    public let progress: Progress
    
    init() {
        progress = Progress()
        progress.cancellationHandler = {}
    }
}

And this simple test:

import Testing

@Test
func reproDispatchAssertQueueFail() async throws {
    let dc = MyController()
    dc.progress.cancel()
}

In this case, MyController is defined in a Package, which the test imports. I cannot reproduce this when MyController is defined in the same file as the test.

Pulling that same code into a brand new sample project, I cannot reproduce this.

Also, I do not see this issue when testing against iOS 17.5, I'm only seeing it on iOS 18 simulators.

Also, it readily reproduces after running the test immediately after a clean and rebuild of the package defining MyController.

Interestingly enough, I just ran our test against Mac Catalyst and it doesn't crash, but I get a purple runtime warning:

warning: data race detected: @MainActor function at MyController.swift:8 was not called on the main thread

Well, that’s weird. I’m sure there’s an obvious explanation for all of this, but it’s eluding me at the moment.

Within our production codebase, I can reproduce with this simple class:

OK. Well that certainly helps simplify the problem. If only it reproduced outside of your main project )-:

I’d like to confirm two things:

• You’re testing this from Xcode 16.0.

• Targeting the iOS 18.0 simulator.

Right?

I just ran our test against Mac Catalyst and it doesn't crash, but I get a purple runtime warning:

That is interesting. It suggests that the compiler thinks that MyController is bound to the main actor. I can’t see anything in your code that would generate that belief.

I have a couple of suggestions. First, add this your code:

enum Test {
    @MainActor static var counter: Int = 0
}

and then in MyController.init() add this:

init() {
    Test.counter += 1
    …

On my machine that generates an error, which is what I’d expect because MyController.init() is not bound to the main actor and so it can’t access directly Test.counter. What happens in your main project test setup?

Second, tweak your setup like this:

progress.cancellationHandler = { @Sendable in }

Does that prevent the trap?

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

I’d like to confirm two things: You’re testing this from Xcode 16.0. Targeting the iOS 18.0 simulator.

Yes on both.

First, add this your code:

The Test.counter line generates this error:

Main actor-isolated static property 'counter' can not be mutated from a nonisolated context

Second, tweak your setup like this: progress.cancellationHandler = { @Sendable in }

Unfortunately, that does not prevent the trap, no.

Thanks for your help.

The Test.counter line generates this error:

Right. That’s the error I’d expect, indicating that the compiler doesn’t think that MyController is main actor isolated. So why is it inserting these asserts? Hmmm, it’s a mystery.

At this point I’m running low on ideas )-: But there’s one last thing I’d like to check. Can you post a full crash report of this issue? See Posting a Crash Report for advice on how to do that.

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

Crash report attached.

Thanks for that.

I had another go at reproducing this myself, with no luck. To investigate further I added a breakpoint in the cancellation handler, that is, on the print(…) call in this slight tweak of your code:

progress.cancellationHandler = {
    print("here")
}

My goal was twofold. First, I wanted to check that the cancellation handler was running in a secondary thread, as shown in your crash report. It is. So my version of your test is replicating that part of the equation.

Here’s that backtrace:

(lldb) bt
* thread #4, queue = 'com.apple.root.user-initiated-qos', stop reason = breakpoint 1.1
  * frame #0: … Test765388.debug.dylib`closure #1 in MyController.init() at MyController.swift:9:19
    frame #1: … Test765388.debug.dylib`thunk for @escaping @callee_guaranteed @Sendable () -> () at <compiler-generated>:0
    frame #2: … Foundation`__20-[NSProgress cancel]_block_invoke_3 + 28
    frame #3: … libdispatch.dylib`_dispatch_call_block_and_release + 24
    frame #4: … libdispatch.dylib`_dispatch_client_callout + 16
    frame #5: … libdispatch.dylib`_dispatch_root_queue_drain + 1072
    frame #6: … libdispatch.dylib`_dispatch_worker_thread2 + 232
    frame #7: … libsystem_pthread.dylib`_pthread_wqthread + 224
…

I then disassembled my part of the equation, that is, frames 0 and 1, looking for where Swift has inserted the swift_task_isCurrentExecutorImpl(…) call that we see in your crash report. It’s just not there.

So, this is clearly something specific to your build setup. You’ve already gone through all the obvious steps to try to isolate this, to no avail. My next recommendation is that you clone your main project and start ripping stuff out of that clone, that it, deleting all the code that’s not necessary to reproduce this issue. Eventually you’ll get to one of two states:

• Something you remove will cause this problem to go away, and that’ll be a useful clue for further investigation.

• You’ll delete all the code that you care about, at which point you can file a bug with that project.

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

I have a reproducible project. I zipped it up but I can't seem to attach a zip file. It's only 91KB

I have a reproducible project.

Yay!

I zipped it up but I can't seem to attach a zip file.

Yeah, DevForums doesn’t support arbitrary attachments )-:

At this point I think it makes sense for you to file a bug about this issue. If you post your bug number here, I can pick up the attachment from there.

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

FB15511118

This continues to be a mystery.

I grabbed the test project you attached to FB15511118 and tried it here in my office. Things continue to work for me. This is testing with Xcode 16.0 on macOS 14.7 targeting an iPhone 16.0 / iOS 18.0 simulator. That’s close enough to your setup that it should reproduce. But it doesn’t )-:

One interesting thing I noticed is that the only other code in your test project is using WebKit, and I’ve seen another weird bug a bit like this, where the compiler misidentifies the concurrency properties of some code. See this thread for the details.

Still, that’s just me clutching at straws. Without being able to reproduce the issue, I’m still in the dark. [Whoah, mixed metaphor!]

I’d like to ask you for help again, to rule out one more potential cause of this problem. If you create a new user account on your Mac (in System Settings > Users & Groups) and use Xcode to run your test over there, does that have the same problem?

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