Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime issues with dynamic properties in App types #222

Closed
carson-katri opened this issue Jul 28, 2020 · 5 comments · Fixed by #223
Closed

Runtime issues with dynamic properties in App types #222

carson-katri opened this issue Jul 28, 2020 · 5 comments · Fixed by #223
Labels
bug Something isn't working

Comments

@carson-katri
Copy link
Member

carson-katri commented Jul 28, 2020

Here's a small example:

struct TokamakDemoApp: App {
  @ObservedObject var count = Count(value: 0)

  var body: some Scene {
    WindowGroup("Tokamak Demo") {
        Text("\(count.value)")
    }
  }
}

crashes with:

RuntimeError: memory access out of bounds
    at strlen (<anonymous>:wasm-function[47490]:0xb8643d)
    at $sSS7cStringSSSPys4Int8VG_tcfCTf4nd_n (<anonymous>:wasm-function[20390]:0x556bae)
    at $sSS7cStringSSSPys4Int8VG_tcfC (<anonymous>:wasm-function[20389]:0x556b68)
    at $s7Runtime19NominalMetadataTypePAAE11mangledNameSSyF (<anonymous>:wasm-function[8313]:0x2150cb)
    at $s7Runtime13ClassMetadataV10toTypeInfoAA0eF0VyF (<anonymous>:wasm-function[8168]:0x20e6a9)
    at $s7Runtime13ClassMetadataVAA19TypeInfoConvertibleA2aDP02todE0AA0dE0VyFTW (<anonymous>:wasm-function[8192]:0x20f2e3)
    at $s7Runtime8typeInfo2ofAA04TypeC0VypXp_tKF (<anonymous>:wasm-function[8660]:0x223bcd)
    at $s11OpenCombine16ObservableObjectPA2A0cD9PublisherC0d10WillChangeE0RtzrlE06objectfG0AEvg (<anonymous>:wasm-function[1705]:0x88986)
    at $s11TokamakDemo5CountC11OpenCombine16ObservableObjectAadEP16objectWillChange0giJ9PublisherQzvgTW (<anonymous>:wasm-function[16762]:0x443ce3)
    at $s11TokamakCore14ObservedObjectV16objectWillChange11OpenCombine12AnyPublisherVyyts5NeverOGvg (<anonymous>:wasm-function[11415]:0x2b6422)

This occurs in Views as well.

Update:

@State also has some issues. Here's a small example:

struct TokamakDemoApp: App {
  @State private var count: Int = 0
  var body: some Scene {
    WindowGroup("Tokamak Demo") {
      Button("\(count)") { count += 1 }
    }
  }
}

The count starts with the number 207884. 🤨

@carson-katri carson-katri changed the title ObservedObject issues Runtime issues Jul 28, 2020
@MaxDesiatov
Copy link
Collaborator

Thanks, I'm looking into it.

@MaxDesiatov MaxDesiatov added the bug Something isn't working label Jul 28, 2020
@MaxDesiatov MaxDesiatov changed the title Runtime issues Runtime issues with dynamic properties in App types Jul 28, 2020
@MaxDesiatov
Copy link
Collaborator

MaxDesiatov commented Jul 28, 2020

The state becomes corrupt within the injectEnvironment function. Making it generic instead of operating on Any fixes it for the first injection, which is called from makeMountedApp where the generic type of the app still known, but as soon as it's wrapped in _AnyApp it's erased completely. I'm looking for a solution/workaround now, but lmk if you have any ideas.

@MaxDesiatov
Copy link
Collaborator

The current signature I use is func injectEnvironment<T>(from environmentValues: EnvironmentValues, into element: inout T), it doesn't require changing anything in the body.

@MaxDesiatov
Copy link
Collaborator

I'm still not sure if it's a bug in the Runtime library or Swift runtime metadata itself. I'm seeing weird behavior with type(of:) API too, which is a part of the standard library. I haven't got good ideas how to diagnose or reproduce it outside of Tokamak for a good test case, but thinking of a workaround, I wonder if adding another generic argument to StackReconciler of App type would help. We then would always have the app type known statically. It is already known, we just type-erase it when wrapping in _AnyApp. We probably wouldn't even need _AnyApp type to exist then.

What remains a mystery to me is why this doesn't happen to AnyView and View types. The bigger problem will be if this is reproducible for _AnyScene and DynamicProperty fields on custom scenes, I'll try to verify this in my mounted-scene branch tomorrow.

@carson-katri
Copy link
Member Author

I actually have seen this issue with ObservedObject in Views while working on Toolbars, but I haven’t been able to replicate it on a smaller scale.

MaxDesiatov added a commit that referenced this issue Jul 29, 2020
Implements support for custom scenes by adding the new `MountedScene` type and fixes environment propagation from mounted parent to mounted child elements.

This will unblock #136 and potentially #214. In the former scenes are always completely unmounted and remounted from scratch when root environment changes, which causes descendants to lose all `@State` values. I saw some environment propagation issues in the latter, but not sure if those were caused by the lack of correct scene updates, just wanted to tackle the usual suspects first.

I've also improved reconciler-related doc comments to clarify some of the design desicions and naming.

Resolves #222.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

Successfully merging a pull request may close this issue.

2 participants