Infinite loops w/ 100% CPU usage caused by stack overflows

[MaxDesiatov]

Describe the bug
There's a certain snippet of code, which when rendererd in the browser triggers an infinite loop after clicking on a NavigationLink.

To Reproduce
Build and run this snippet with carton dev:

import TokamakShim

struct TokamakApp: App {
  var body: some Scene {
    WindowGroup("Spooky Hanger") {
      NavigationView {
        List {
          ForEach(["Section"], id: \.self) { section in
            Section(header: Text(section).font(.headline)) {
              ForEach(["Item 1"], id: \.self) { childRow in
                NavigationLink(
                  destination: Text(childRow).padding([.leading, .trailing])
                ) {
                  Text(childRow)
                }
                .padding(.leading)
              }
            }
          }
        }
        .listStyle(SidebarListStyle())
      }
    }
  }
}

TokamakApp.main()

Open it in any browser a tap on "Item 1". Sometimes it loads the destination, but frequently it just hangs. If it doesn't hang, reload the page and try again. It's usually reproducible at least one in five attempts. I've reproduced in Safari, Firefox, and Chrome.

Expected behavior
NavigationLink always opens the destination without any problems.

Screenshots

Additional context

This was reported by @foscomputerservices in a bigger project, but I've managed to reduce it to this snippet. I've tried to remove seemingly unrelated modifiers or views, like listStyle or padding, but removing them seems to make the issue go away or reduce the probability or reproduction steps to something I can't trigger anymore.

[MaxDesiatov]

Occasionally (but not always!) I'm able to catch an OOB with this in Chrome:

[MaxDesiatov]

I've been sticking print(#function); defer { print("exit \(#function)") } in too many places in the reconciler and the DOM renderer, but the actual source of the loop is very elusive. With every added print the place of OOB changes, or the OOB itself goes away. The only thing that gives me hope is that this is stably reproducible (even OOBs) with the same source code in all browsers, so this isn't some kind of Wasm VM optimizer issue, but certainly something with Tokamak, SwiftWasm, or the Runtime library.

@kateinoigakukun please help, my debugging skills are not good enough for this. My only hypothesis is that something's weird with the metadata (maybe the Runtime library misreads some fields?) and this somehow messes everything up.

[MaxDesiatov]

Also, I've verified that this is reproducible in both main and 0.6.1, so it was introduced some time ago even if it wasn't present right from the start. I haven't checked with 0.5.3 yet as it requires an older version of carton.

[MaxDesiatov]

Reopening, as this issue is still reproducible in main with just a few print statements added across the codebase 😢

Thanks to @foscomputerservices for uncovering this!

[MaxDesiatov]

I've pushed the changes to a branch if anyone's interested in reproducing it on their side.

[MaxDesiatov]

TWIMC, all points to this being a stack overflow issue, the immediate workaround is to add these flags to your Package.swift:

linkerSettings: [
  .unsafeFlags(["-Xlinker", "--stack-first", "-Xlinker", "-z", "-Xlinker", "stack-size=16777216"]),
]

The required stack size may be bigger to accommodate for bigger view hierarchies.

The most probable long-term fix will probably require Tokamak to allocate some more on the heap. As @kateinoigakukun said:

TokamakCore.MountedHostView.update consumes 864 bytes for each call, and the deep view-tree accelerates the consumption. Then the total consumed space is nearly 64KB, which is a default stack size wasm-ld allocates.

[foscomputerservices]

This solves the issues that I was having. Thank you for all of your efforts!

[MaxDesiatov]

linkerSettings: [
  .unsafeFlags(["-Xlinker", "--stack-first", "-Xlinker", "-z", "-Xlinker", "stack-size=16777216"]),
]

Had a question asked about it, wanted to clarify that linkerSettings should be passed as the last argument to .target: https://developer.apple.com/documentation/swift_packages/target

[MaxDesiatov]

We have a sanitizer shipped and enabled by default for debug builds in carton 0.10.0. I think we can consider the issue to be resolved now.

[gregcotten]

Hey wait I just had this issue!

I was getting it when an ObservableObject was subscribed to an Electron IPC listener and was making @published updates. The 100% CPU on the renderer process only showed up when the chromium window became completely occluded, strangely. Anyway, using the aforementioned flags worked for me:

linkerSettings: [
  .unsafeFlags(["-Xlinker", "--stack-first", "-Xlinker", "-z", "-Xlinker", "stack-size=16777216"], .when(platforms: [.wasi]),
]