Crash in app.rive.command-server during CommandServer teardown after RiveUIView deallocation

[wlixcc]

Submission checklist

• I have confirmed the issue is present in the latest version of RiveRuntime
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

Description

We are seeing an intermittent production crash from Crashlytics when a RiveUIView used as a launch screen animation is removed and released.

The crash happens on Rive's background command server thread during teardown:

Crashed: app.rive.command-server
0  libdispatch.dylib   _dispatch_semaphore_dispose.cold.1
1  libdispatch.dylib   _dispatch_semaphore_signal_slow
2  libdispatch.dylib   _dispatch_dispose
3  RiveRuntime         RiveHitResultFromRuntime(rive::HitResult)
...
11 RiveRuntime         rive::CommandServer::~CommandServer()
12 RiveRuntime         rive::CommandServer::~CommandServer()

This may be related to other lifecycle / teardown issues in the new async runtime, especially:

• EXC_BAD_ACCESS crash in CommandQueue::processMessages() on teardown after setValue #418: EXC_BAD_ACCESS in CommandQueue::processMessages() during teardown after setValue
• fix: eager listener cleanup via onXxxDeleted callbacks #420: proposed eager listener cleanup for resources repeatedly created/destroyed while a Worker stays alive
• Memory leak when reusing a shared Worker across multiple Rive instances (canonical caching pattern) #439: memory leak / incomplete cleanup when reusing Worker across multiple Rive instances

However, this crash stack looks different because it happens during rive::CommandServer destruction, with _dispatch_semaphore_dispose / _dispatch_semaphore_signal_slow at the top of the crashed thread.

Previous working version

No response

Rive Apple runtime version

6.19.0

Reproduction steps / code

Reproduction steps / code

We have not been able to reproduce this deterministically in a small sample app yet. The production crash happens during launch-screen teardown, when a temporary RiveUIView is removed from the view hierarchy and the owning view is released.

The relevant usage pattern is:

1. Create a temporary UIKit launch screen view.
2. Inside that view, create a RiveUIView(rive: nil).
3. Load a local .riv file using the new async runtime:
   • Worker
   • File
   • Artboard
   • StateMachine
   • ViewModelInstance
   • Rive
4. Assign the resulting Rive instance to riveView.rive.
5. After the launch flow completes, remove the launch screen from the view hierarchy.
6. Immediately release the owning launch screen view.
7. Crashlytics intermittently reports a crash on app.rive.command-server during rive::CommandServer teardown.

Reduced version of the production code:

import UIKit
import RiveRuntime

final class LaunchScreenView: UIView {
    private let phaseProperty = NumberProperty(path: "phase")
    private var launchViewModelInstance: ViewModelInstance?
    private var riveLoadTask: Task<Void, Never>?

    private lazy var riveView: RiveUIView = {
        let view = RiveUIView(rive: nil)
        view.backgroundColor = .clear
        return view
    }()

    override init(frame: CGRect) {
        super.init(frame: frame)

        addSubview(riveView)
        riveView.frame = bounds
        riveView.autoresizingMask = [.flexibleWidth, .flexibleHeight]

        loadRiveAnimation()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    deinit {
        riveLoadTask?.cancel()
    }

    private func loadRiveAnimation() {
        riveLoadTask = Task { [weak self] in
            await self?.prepareRiveAnimation()
        }
    }

    @MainActor
    private func prepareRiveAnimation() async {
        do {
            let worker = try await Worker()
            let file = try await File(source: .local("launch", Bundle.main), worker: worker)
            let artboard = try await file.createArtboard()
            let stateMachine = try await artboard.createStateMachine("LaunchStateMachine")

            let viewModelInstance = try await file.createViewModelInstance(
                .blank(from: .name("LaunchViewModel"))
            )
            viewModelInstance.setValue(of: phaseProperty, to: 1)

            let rive = try await Rive(
                file: file,
                artboard: artboard,
                stateMachine: stateMachine,
                dataBind: .instance(viewModelInstance),
                fit: .contain(alignment: .center)
            )

            launchViewModelInstance = viewModelInstance
            riveView.rive = rive
        } catch {
            print("Failed to load Rive launch animation: \(error)")
        }
    }

    @MainActor
    func updatePhase(_ phase: Float) {
        launchViewModelInstance?.setValue(of: phaseProperty, to: phase)
    }
}

The launch view is owned by a UITabBarController and released immediately after the launch transition finishes:

final class RootTabBarController: UITabBarController {
    private var launchScreenView: LaunchScreenView? = LaunchScreenView()

    func startLaunchTransition() {
        guard let launchScreenView else { return }

        view.addSubview(launchScreenView)
        launchScreenView.frame = view.bounds
        launchScreenView.autoresizingMask = [.flexibleWidth, .flexibleHeight]

        launchScreenView.updatePhase(1)

        DispatchQueue.main.asyncAfter(deadline: .now() + 1.8) { [weak self] in
            self?.finishLaunchTransition()
        }
    }

    private func finishLaunchTransition() {
        guard let launchScreenView else { return }

        UIView.animate(withDuration: 0.25) {
            launchScreenView.alpha = 0
        } completion: { [weak self] _ in
            launchScreenView.removeFromSuperview()

            // Releasing this temporary view releases RiveUIView / Rive / Worker.
            // Crashlytics intermittently reports a crash shortly after this,
            // on the `app.rive.command-server` thread.
            self?.launchScreenView = nil
        }
    }
}

The Crashlytics stack suggests the crash happens after this release path, while RiveRuntime is tearing down the worker command server:

Crashed: app.rive.command-server
0  libdispatch.dylib   _dispatch_semaphore_dispose.cold.1
1  libdispatch.dylib   _dispatch_semaphore_signal_slow
2  libdispatch.dylib   _dispatch_dispose
3  RiveRuntime         RiveHitResultFromRuntime(rive::HitResult)
...
11 RiveRuntime         rive::CommandServer::~CommandServer()
12 RiveRuntime         rive::CommandServer::~CommandServer()


### Upload your reproduction files / stack trace

_No response_

### Source `.riv` / `.rev` file

_No response_

### Screenshots / video

_No response_

### Device

iPad (11th generation)，iPhone 11，iPhone XS Max

### Apple OS version

iPadOS 26.2.0，iOS 16.1.1，iOS 17.1.2，iOS 15.8.4

### Additional context

_No response_

[dskuza]

Thank you for the report! The sample code should help in my debugging environment.

The following line is interesting:

3 RiveRuntime RiveHitResultFromRuntime(rive::HitResult)

Do you have any touch inputs added to your view? Ideally it'd be best if I could try and reproduce with the file you are using. I understand that it's a production file, so if there was another way for us to do a private file hand-off, would you be okay doing so? It would be for internal debugging only.

[wlixcc]

Thanks for looking into this.

Regarding touch inputs: we do not intentionally add custom touch handling or gesture recognizers to the Rive view itself. However, one detail that may be relevant is that after the launch animation starts, an ad may sometimes be shown on top of or near this view. In that case, the Rive view may still be in the view hierarchy while the ad overlay introduces additional touch handling / gesture recognizers, so touches from the ad flow could potentially be related.

I’ll also verify whether the Rive file itself contains any state machine listeners / pointer interactions.

About the file: yes, I’m open to sharing it privately for internal debugging only, but we can’t attach the production file publicly in this issue. Could you provide a private hand-off method, such as a private upload link, email, or another secure channel?

[dskuza]

You can send your file(s) to support@rive.app with a link to this issue and I'll make sure it gets assigned to me. Can you also attach the entire stack trace as well?

[wlixcc]

Thanks. I’ve sent the files to support@rive.app with a link to this issue.

[dskuza]

@wlixcc Message received!

[dskuza]

@wlixcc Question for you: the crash reports aren't showing what the exception type is. Does your crash reporter show that on your end? E.g EXC_BREAKPOINT, EXC_BAD_ACCESS, etc

[wlixcc]

I checked Firebase Crashlytics. It shows:

Crashed: app.rive.command-server
SIGTRAP 0x00000001d8c11c20

My understanding is that this usually corresponds to EXC_BREAKPOINT.

Let me know if there are any other Crashlytics fields that would help.

[wlixcc]

I also found another Crashlytics event with a very similar stack.

It shows:

Crashed: com.Metal.CompletionQueueDispatch
SIGTRAP 0x000000018be1d6f0

Top frames:

0 libdispatch.dylib  _dispatch_semaphore_dispose.cold.1 + 40
1 libdispatch.dylib  _dispatch_semaphore_signal_slow + 70
2 libdispatch.dylib  _dispatch_dispose + 208
3 RiveRuntime        RiveHitResultFromRuntime(rive::HitResult) + 341992

[dskuza]

I think I have a fix. I'm hoping to have a release later this week that'll include it!

[dskuza]

@wlixcc I just released v6.20.1, which has the (hopeful) fix for this. I say hopeful because I haven't been able to reproduce it locally, but the consistent stack traces made it somewhat easier to track down what the root cause could have been.

[wlixcc]

@dskuza Thanks for the quick fix and release!

I’ll upgrade to v6.20.1 and monitor Crashlytics in production. Since we also couldn’t reproduce this reliably locally, production data should help confirm whether the fix works.

If we don’t see this issue again after monitoring for 1-2 weeks in production, I’ll close this issue. I’ll update here if the same stack trace appears again after the upgrade.

[wlixcc]

@dskuza The problem has not recurred. Thank you very much for updating the SDK in time. I will now close this issue.