Blazor worker "memory access out of bounds" bug

[StachuDotNet]

seems to happen only with very large requests.

• https://stackoverflow.com/questions/57938081/blazor-preview-9-mono-wasm-memory-access-out-of-bounds-max-string-size-for-dotn
• https://www.reddit.com/r/WebAssembly/comments/g44ldd/what_are_some_possible_causes_of_runtimeerror/
• Apply default memory limit in Mono env dotnet/aspnetcore#5617

[StachuDotNet]

Weird - I think this is actually happening before the request was made. Maybe I was interpreting things before.
Edit: nevermind.

[StachuDotNet]

I've now gotten the analysis request payload that causes the issue.
It's indeed quite large (70814 chars of JSON).

FWIW this request seems to include a lot of stuff that it doesn't need to perform the analysis. (though I haven't verified this)

I'm seeing three paths forward:

• somehow increase the memory limit (so far, this seems impossible without recompiling blazor and mono/wasm)
• send less stuff in the request (i.e. filter out stuff not needed for analysis)
• send the request in batches, e.g. per https://stackoverflow.com/a/57973792 or "as a file."
  I suppose we could create a .json file, and send that across the wire? haven't looked into this yet.

Currently experimenting to see what the char threshold of failure is.

[StachuDotNet]

One more path forward: if the request is huge, ask the backend instead of wasm.
(we could do this for a bit, and follow up with other options later)

[StachuDotNet]

Note: I can replicate this in Release AOT builds, but not Debug builds.
Now checking to see if I can repro in a non-AOT release build.

[StachuDotNet]

Seems I can't - i.e. the bug seems AOT-specific.
Edit: still didn't determine char threshold of failure - actually testing that now.

[pbiggar]

Do you know what function this is happening in? Perhaps we're able to separate reading the json from doing the analysis in some way. Maybe we parse the json in JS code and then call wasm using JSInterop or whatever it's called.

[StachuDotNet]

Do you know what function this is happening in?

Maybe I'm answering the wrong question, but:

once we've defined messageHandler
const messageHandler = Module.mono_bind_static_method("[Wasm]Wasm.EvalWorker:OnMessage");

calling messageHandler(hugePayload); is what breaks it - we don't get to the first line of OnMessage (though, likely because we couldn't read to avail the message arg)

Maybe we parse the json in JS code and then call wasm using JSInterop or whatever it's called.

I don't know what you mean by this. Could you please spell it out?

[pbiggar]

Spelt out below but I think the fact that it happens before OnMessage might scupper what I was suggesting.

Currently we do:

let callWasm data = 
  let parsed = parseData(data) // happens in F#/WASM
  execute(parsed) // more F#/Wasm
callWasm data // JS caller

Could we instead do:

parsed = parseDataInJS(data); // happens in JS
callWasm(parsed) // F# code happens within here

[pbiggar]

• send the request in batches, e.g. per https://stackoverflow.com/a/57973792 or "as a file."
  I suppose we could create a .json file, and send that across the wire? haven't looked into this yet.

That's a good idea.

[StachuDotNet]

TIL "scupper."

Yeah I don't think that'll work (because we don't get to OnMessage)

---

So, seems we have two options:

• create a .json file, "upload" it, and then process that upload. (not yet sure how this will pan out...)
• (more manual) break down the request into multiple messages, send them chunk by chunk as requests, update Wasm.fs to wait for all of the requests (likely with some little protocol to ensure ordering and a signal that "we're done sending"), and then process the request.

I'm currently trying to see if anything inhttps://github.com/Tewr/BlazorFileReader/blob/main/src/Blazor.FileReader/Tewr.Blazor.FileReader.md could help us out. Or maybe there's something official. It's hard to not be distracted by all of the view/Razor-specific stuff in this Blazor world.

[pbiggar]

Yeah, either of those sound good. I like the ArrayBuffer/file approach but does that also have size limits?

Are we sure this is the problem though? 76k isn't small but it's also not huge. The Stackoverflow thing says the limit is over 50MB now.

[StachuDotNet]

I'm now a bit less confident.

I added this to Wasm.fs:

  static member CanWeGetHere(message : string) =
    message |> String.length |> printfn "Yes %i"

and posted the giant json to that handler rather than the OnMessage one. It works? Digging in..

[StachuDotNet]

I was wrong before! We are getting to within OnMessage. We're even deserializing OK. The failure seems to be happening within the actual analysis.

Added some logs; waiting for another AOT build - seems we're closer.

[StachuDotNet]

Even more interesting:

with my code like this:

 let! result =
        task {
          match args with
          | Error e -> return Error e
          | Ok args ->
            try
              printfn "Performing analysis"
              let! result = Eval.performAnalysis args
              printfn "Performed analysis"
              return Ok result
            with
            | e ->
              let metadata = Exception.nestedMetadata e
              System.Console.WriteLine("Error running analysis in Blazor")
              System.Console.WriteLine($"called with message: {message}")
              System.Console.WriteLine(
                $"caught exception: \"{e.Message}\" \"{metadata}\""
              )
              return Error($"exception: {e.Message}, metadata: {metadata}")
        }

      printfn "Serializing result"
      let serialized =
        try
          Json.Vanilla.serialize result
        with
        | e ->
          let metadata = Exception.nestedMetadata e
          System.Console.WriteLine("Error serializing results of Blazor analysis")
          System.Console.WriteLine($"called with message: {message}")
          System.Console.WriteLine(
            $"caught exception: \"{e.Message}\" \"{metadata}\""
          )
          Json.Vanilla.serialize ($"exception: {e.Message}, metadata: {metadata}")

      printfn "Posting result back"
      EvalWorker.postMessage serialized

I got "performed analysis" and it dies right after, without ever emitting Serializing result. Maybe something to do with the task.