EXC_BAD_ACCESS crash after migrating to ObservableState

[chwo]

Description

After migrating our app to ObservableState and WithPerceptionTracking the app crashes directly at the app start: Thread 1: EXC_BAD_ACCESS (code=2, address=0x16ef03ff8)

The crash can't be resolved by a full clean and rebuild.
Without the ObservableState changes the crash doesn't occur and the app runs fine.

I thought using ObservableState would bring a performance gain by reducing the number of TCA internal scopings. So I am surprised that it seems to be increasing the stack size usage leading to this crash.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The app doesn't crash after migrating to ObservableState.

Actual behavior

The app crashes after migrating to ObservableState.

Steps to reproduce

Unfortunately, I wasn't able to isolate this in a reproducible sample project yet.

We use Stack-based navigation with 15 paths but this isn't a high number compared to this issue: #3162.
However when commenting-out some features in our navigation stack the crash doesn't occur anymore. But this doesn't seem to be specific to particular features and rather concerns the overall number of features. That's why I'm afraid it that it could have something to do with stack size (like in other EXC_BAD_ACCESS issues in this repo).

For reference how we use the Stack-based navigation:

@Reducer
public struct NavigationFeature {
    @ObservableState
    public struct State {
        public var root: Screen.State
        public var path = StackState<Screen.State>()

        public init(root: Screen.State) {
            self.root = root
        }
    }

    public enum Action {
        case path(StackAction<Screen.State, Screen.Action>)
        case root(Screen.Action)
    }

    public var body: some ReducerOf<Self> {
        Scope(state: \.root, action: \.root) {
            Screen()
        }
        .forEach(\.path, action: \.path) {
            Screen()
        }
    }
}

@Reducer
public struct Screen {
    @ObservableState
    public enum State {
        case editorial(EditorialFeature.State)
        case stream(StreamFeature.State)
        case settings(SettingsFeature.State)
        case debug(SettingsDebugFeature.State)
        case radar(RadarFeature.State)
    }

    public enum Action {
        case editorial(EditorialFeature.Action)
        case stream(StreamFeature.Action)
        case settings(SettingsFeature.Action)
        case debug(SettingsDebugFeature.Action)
        case radar(RadarFeature.Action)
    }

    public var body: some ReducerOf<Self> {
        Scope(state: \.editorial, action: \.editorial) {
            EditorialFeature()
        }
        Scope(state: \.stream, action: \.stream) {
            StreamFeature()
        }
        Scope(state: \.settings, action: \.settings) {
            SettingsFeature()
        }
        Scope(state: \.debug, action: \.debug) {
            SettingsDebugFeature()
        }
        Scope(state: \.radar, action: \.radar) {
            RadarFeature()
        }
    }
}

public struct NavigationFeatureView: View {
    @Perception.Bindable var store: StoreOf<NavigationFeature>

    public init(store: StoreOf<NavigationFeature>) {
        self.store = store
    }

    public var body: some View {
        WithPerceptionTracking {
            NavigationStack(path: $store.scope(state: \.path, action: \.path)) {
                createView(store: store.scope(state: \.root, action: \.root))
            } destination: { store in
                createView(store: store)
            }
        }
    }

    @ViewBuilder
    private func createView(store: StoreOf<Screen>) -> some View {
        switch store.state {
        case .stream:
            if let store = store.scope(state: \.stream, action: \.stream) {
                StreamFeatureView(store: store)
            }
        case .editorial:
            if let store = store.scope(state: \.editorial, action: \.editorial) {
                EditorialFeatureView(store: store)
            }
        case .debug:
            if let store = store.scope(state: \.debug, action: \.debug) {
                SettingsDebugFeatureView(store: store)
            }
        case .settings:
            if let store = store.scope(state: \.settings, action: \.settings) {
                SettingsFeatureView(store: store)
            }
        case .radar:
            if let store = store.scope(state: \.radar, action: \.radar) {
                RadarFeatureView(store: store)
            }
        }
    }
}

Do you have an idea or any tips how I can further narrow down the issue?

The Composable Architecture version information

1.13.0

Destination operating system

iOS 16

Xcode version information

Xcode 15.4 (15F31d)

Swift Compiler version information

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

[lukeredpath]

Whilst the TCA navigation tools should mitigate stack size problems relating to state (as the state is stored in a reference type internally), it does not mitigate the issue of large action enums blowing the stack - does making some of your path's action enums indirect solve the problem?

[chwo]

@lukeredpath Thank you for the suggestion. Making the action enums indirect prevents the crash directly at the app start but it still occurs when navigating to detail screens. However I did find another solution based on your answer in another discussion (see below).
So using indirect is not necessary - but are there any downsides of using it or is the general advice to not use it to keep it simple?

[lukeredpath]

@chwo I would only use indirect if I had determined that a large action enum was causing the stack overflow. Marking it as indirect should be safe but may incur a performance cost by moving the storage off the stack and on to the heap.

[mbrandonw]

Hi @chwo, there are a few reasons this can happen (@lukeredpath mentioned some), but in order for anyone to help you would need to provide more context. Ideally you would even be able to reproduce the problem in a sample project that can be shared.

Here are some things to keep in mind:

• If you see something in the stack trace that contains __chkstk_darwin then it is a stack overflow.
• Are you using the library's navigation tools?
• Does it crash in RELEASE builds? Or just DEBUG builds?

Either way, this is not an issue with the library, and so I am going to convert it to a discussion. Please feel free to continue the conversation over there.

[chwo]

@mbrandonw Thank you for the input.

• The crash happens both in DEBUG and RELEASE builds
• Yes we are using TCA Stack-based navigation (see steps to reproduce for the simplified setup)
• The stack trace does indeed contain __chkstk_darwin

Further investigating the __chkstk_darwin message has led me to this discussion #3063 by which I was able to identify and solve the crash.

The cause is our main content view which consists of multiple (up to 25) cards. Each card is self-contained and independent of the other cards so each card is its own feature and all card states are held in the parent feature. See minimal example with 5 cards below. The crash doesn't happen in this simplified example even with more cards because the card states are probably too small.

@Reducer
public struct StreamFeature {
    public enum Card: CaseIterable {
        case card1, card2, card3, card4, card5
    }

    @ObservableState
    public struct State {
        var card1: StreamCard1Feature.State
        var card2: StreamCard2Feature.State
        var card3: StreamCard3Feature.State
        var card4: StreamCard4Feature.State
        var card5: StreamCard5Feature.State

        public init(
            card1: StreamCard1Feature.State = .init(),
            card2: StreamCard2Feature.State = .init(),
            card3: StreamCard3Feature.State = .init(),
            card4: StreamCard4Feature.State = .init(),
            card5: StreamCard5Feature.State = .init()
        ) {
            self.card1 = card1
            self.card2 = card2
            self.card3 = card3
            self.card4 = card4
            self.card5 = card5
        }
    }

    @CasePathable
    public enum Action {
        case buttonTapped
        case card1(StreamCard1Feature.Action)
        case card2(StreamCard2Feature.Action)
        case card3(StreamCard3Feature.Action)
        case card4(StreamCard4Feature.Action)
        case card5(StreamCard5Feature.Action)
    }

    public init() {}

    public var body: some Reducer<State, Action> {
        ReducerBuilder<State, Action>.buildArray(Card.allCases.map(Self.createReducer(card:)))

        Reduce { state, action in
            switch action {
            case .buttonTapped:
                return .none
            case .card1(.delegate(.doSomething)):
                print("Card1 doSomething")
                return .none
            case .card1, .card2, .card3, .card4, .card5:
                return .none
            }
        }
    }

    @ReducerBuilder<State, Action>
    static func createReducer(card: Card) -> some Reducer<State, Action> {
        switch card {
        case .card1:
            Scope(state: \.card1, action: \.card1) {
                StreamCard1Feature()
            }
        case .card2:
            Scope(state: \.card2, action: \.card2) {
                StreamCard2Feature()
            }
        case .card3:
            Scope(state: \.card3, action: \.card3) {
                StreamCard3Feature()
            }
        case .card4:
            Scope(state: \.card4, action: \.card4) {
                StreamCard4Feature()
            }
        case .card5:
            Scope(state: \.card5, action: \.card5) {
                StreamCard5Feature()
            }
        }
    }
}

public struct StreamFeatureView: View {
    private let store: StoreOf<StreamFeature>

    public init(store: StoreOf<StreamFeature>) {
        self.store = store
    }

    public var body: some View {
        ScrollView {
            VStack(spacing: 20) {
                Button("StreamFeatureView button") {
                    store.send(.buttonTapped)
                }
                Text("Cards below")

                ForEach(StreamFeature.Card.allCases, id: \.self, content: createStreamCardView(card:))
            }
            .frame(maxWidth: .infinity)
        }
    }

    @ViewBuilder
    func createStreamCardView(card: StreamFeature.Card) -> some View {
        WithPerceptionTracking {
            switch card {
            case .card1:
                StreamCard1FeatureView(store: store.scope(state: \.card1, action: \.card1))
            case .card2:
                StreamCard2FeatureView(store: store.scope(state: \.card2, action: \.card2))
            case .card3:
                StreamCard3FeatureView(store: store.scope(state: \.card3, action: \.card3))
            case .card4:
                StreamCard4FeatureView(store: store.scope(state: \.card4, action: \.card4))
            case .card5:
                StreamCard5FeatureView(store: store.scope(state: \.card5, action: \.card5))
            }
        }
    }
}

@Reducer
public struct StreamCard1Feature {
    @ObservableState
    public struct State: Equatable {
        var test: String

        public init(test: String = "lorem ipsum") {
            self.test = test
        }
    }

    public enum Action {
        case buttonTapped
        case delegate(Delegate)

        public enum Delegate {
            case doSomething
        }
    }

    public var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .buttonTapped:
                return .send(.delegate(.doSomething))
            case .delegate:
                return .none
            }
        }
    }
}

public struct StreamCard1FeatureView: View {
    private let store: StoreOf<StreamCard1Feature>

    public init(store: StoreOf<StreamCard1Feature>) {
        self.store = store
    }

    public var body: some View {
        VStack {
            Text("StreamCard1FeatureView")
            Button("Button") {
                store.send(.buttonTapped)
            }
        }
    }
}

So the working solution based on #3063 (comment) is to annotate all card states with @ObservationStateIgnored @ObservedBox.

@ObservableState
public struct State {
+   @ObservationStateIgnored @ObservedBox
    var card1: StreamCard1Feature.State
+   @ObservationStateIgnored @ObservedBox
    var card2: StreamCard2Feature.State
+   @ObservationStateIgnored @ObservedBox
    var card3: StreamCard3Feature.State
+   @ObservationStateIgnored @ObservedBox
    var card4: StreamCard4Feature.State
+   @ObservationStateIgnored @ObservedBox
    var card5: StreamCard5Feature.State
}

To conclude, I have the following questions regarding the solution:

• Is this is viable and sustainable solution?
• IMHO it is a valid use case to have multiple distinct child features in a parent feature. Can you consider shipping the @ObservedBox property wrapper as part of the library so that one does not have to manually maintain it.
• We don’t access the child states in the parent feature. In the parent feature, we only react to delegate actions from the cards. So, as an alternative approach, instead of holding each card state in the parent individually, I think we could also create an enum-based card feature that consists of all cards and only holds an array of that card feature in the parent. I have not tried this yet, but I think utilizing the array should work around the stack size problem. Would that be a better solution than the COW property wrapper?

[lukeredpath]

Sounds like you've identified the cause of your stack overflow. I think in your use case, I would be tempted to use an array as internal storage for the card states rather than boxing each one up in a CoW wrapper (a collection already uses heap storage internally so will have the same effect). You would of course need to wrap the values in an enum case in order to store the different states in a collection so it adds some additional complexity.

[mbrandonw]

The cause is our main content view which consists of multiple (up to 25) cards. Each card is self-contained and independent of the other cards so each card is its own feature and all card states are held in the parent feature.

I don't think it's a good idea to literally hold onto 25 fields of child feature state in a parent feature. This would be problematic in any Swift app, not just TCA.

FWIW, we ran into this issue while building isowords. We modeled a Three<A> type for holding onto three values of A, and then we nested them Three<Three<Three<A>>> to represent all the faces of a 3x3x3 cube. That is 27 faces, and of course we ran into stack overflows with that domain modeling.

So, we refactored the Three<A> type so that it secretly holds onto an array of data under the hood, but exposes only a first, second and third publicly. This makes Three act just as it did before, but we get the benefits of heap allocation.

Is this is viable and sustainable solution?

Yes it's perfectly fine. This is just an issue with Swift in general, and not really an issue with TCA. Sure you may run into this more frequently with TCA because of the library's push towards value types, but it's possible to run into problems in vanilla SwiftUI too.

IMHO it is a valid use case to have multiple distinct child features in a parent feature. Can you consider shipping the @ObservedBox property wrapper as part of the library so that one does not have to manually maintain it.

We can consider it, but right now we think that most people avoid this problem by using our presentation tools, which automatically inserts a heap allocated wrapper at each presentation node. So if FeatureA presents FeatureB, then FeatureB's state is wrapped in the box.