fermyon / spin-dotnet-sdk

Apache License 2.0
43 stars 11 forks source link

update to latest Wasi.Sdk and latest Wizer #34

Closed dicej closed 1 year ago

dicej commented 2 years ago

Wizer now has partial support for bulk memory operations, which allows us to use the latest Wasi.Sdk and enjoy the benefits of reduced memory usage (50MB vs. 500MB).

Signed-off-by: Joel Dice joel.dice@fermyon.com

radu-matei commented 2 years ago

I'm having issues running the hello world sample:

Running wizer to preinitialize bin/Release/net7.0/HelloWorld.Spin.wasm...
EXEC : error : the `wizer.initialize` function trapped [/Users/radu/projects/src/github.com/fermyon/spin-dotnet-sdk/samples/hello-world/HelloWorld.Spin.csproj]

  Caused by:
      wasm trap: out of bounds memory access
      wasm backtrace:
          0: 0x403e33 - <unknown>!<wasm function 7544>
itowlson commented 2 years ago

I'm getting the same error here (WSL Ubuntu 20.04)

itowlson commented 2 years ago

It looks like there are some (synthetic?) types on which iterating methods and their attributes now blows up, e.g. <Module> and EmbeddedAttribute. If I artificially filter on name so that only the Handler class is scanned, it seems to work okay.

dicej commented 2 years ago

I don't know why I wasn't able to repro this earlier, but now I'm getting the same "out of bounds memory access" error.

itowlson commented 2 years ago

Correction: looks like it might be happening while trying to free the <Module> class object (and perhaps also the EmbeddedAttribute one? Not sure). Sorry, I have a perpetual problem with outputting trace statements from the C side, so it can be misleading...

itowlson commented 2 years ago

If I remove the mono_free(klass) line then it seems to work.

In fact if I selectively skip it for <Module> only then it seems to work. (So EmbeddedAttribute was probably a red herring - sorry.)

itowlson commented 2 years ago

The same error happens at run time if Wizer is turned off (haven't dived into it, but it but looks like the same trace). So is general to the Wasi.Sdk-related changes, not specific to Wizer.

Freeing the class objects is probably unnecessary - I did it in case there were a lot of them, but doubt it would make a huge impact on memory usage in most cases. Still curious why this particular type causes a memory access trap on free (and why it didn't before, or whether we were just getting lucky before or something!).

dicej commented 2 years ago

@itowlson Do you happen to know if there's been any progress on the "out of bounds memory access" issue? Is there an upstream bug somewhere I can follow?

jpflueger commented 1 year ago

I did not mean to close this and TBH I'm not sure how I did. I just merged my PR and then this PR was automagically closed at the same time. Apologies!