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

Allow setting fs in WASI config #303

Merged
merged 4 commits into from
Nov 18, 2022

Conversation

corwin-of-amber
Copy link
Contributor

I noticed the use case where fs is passed in config is unhandled, and I assume it was because wasm-bound MemFS does not implement JsCast, making it hard to pass it to JS and then get it back in the WASI ctor.

I have adopted some common wisdom that I've found on github to get the wrapped instance from a JS object and pass it along. Are you interested?

Using some boilerplate to get the instance from a JS object.
@syrusakbary
Copy link
Member

Hey, thanks for the PR @corwin-of-amber . Could you also add tests to verify that the API works as expected? Thanks!

@corwin-of-amber
Copy link
Contributor Author

Did it :)

@corwin-of-amber
Copy link
Contributor Author

I think this fix has a bug: it seems that Rust takes ownership of the passed object making it invalid to use it from JS. This should probably not be the correct behavior. I am testing a modified version now.

The JS instance becomes unusable, and trying to access it from JS leads to read from freed memory.
Since MemFS is garbage-collected anyway (via Arc) it makes sense to clone the reference.
JS clients should explicitly free if they do not want to use the fs instance anymore,
to have the reference count decremented.
@corwin-of-amber
Copy link
Contributor Author

I don't really know how to test for the buggy case, because the test passed even before the fix. Thing is, even if a dangling pointer exists the accesses will still succeed immediately after the call, because the memory has not been reclaimed/overwritten yet. This is what made it hard to see the problem in the first place.

@corwin-of-amber
Copy link
Contributor Author

wdyk I found the exact same function in Wasmer API:
https://github.com/wasmerio/wasmer/blob/f1a792e5fc7cd376fe11fafdbe8180e5b76add1e/lib/api/src/js/trap.rs#L254

probably from the same source.

@syrusakbary
Copy link
Member

Were you able to move forward with this @corwin-of-amber ?

@corwin-of-amber
Copy link
Contributor Author

I do not have a systematic approach to testing but I have used this branch for quite some time and tried different programs including ocamlrun and busybox, so I am pretty confident that it does not crash.

@corwin-of-amber
Copy link
Contributor Author

corwin-of-amber commented Nov 15, 2022

wdyk I found the exact same function in Wasmer API: https://github.com/wasmerio/wasmer/blob/f1a792e5fc7cd376fe11fafdbe8180e5b76add1e/lib/api/src/js/trap.rs#L254

probably from the same source.

If you are wondering about this, yes I assume wasmer-js can use the function from js/trap, but I do feel that my version provides better error reporting so perhaps you should merge them?

(actually I have improved the error reporting further in my other branch so I should update this PR)

Used e.g. when passing MemFS via config.
@syrusakbary syrusakbary merged commit a696e1f into wasmerio:main Nov 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants