Stream: git-wasmtime

Topic: wasmtime / issue #6914 Problems with file system calls fr...


view this post on Zulip Wasmtime GitHub notifications bot (Aug 26 2023 at 13:04):

rbackhouse opened issue #6914:

I am unable to get file system calls to work from a tinygo based WASM component. All calls return "errno 76" "capabilities insufficient".

This originally started as a discussion on Zulip with Pat Hickey.
https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Problem.20with.20WasiCtxBuilder.2Epush_preopened_dir.20for.20component

Test Case

I've created a test case available at

https://github.com/rbackhouse/component-go-fs-test

The README details the prereqs and how to build and run.

Here are the wasm files built
testfswasm.zip

Steps to Reproduce

See README from https://github.com/rbackhouse/component-go-fs-test

Expected Results

stdout should show

""test.log created"

Actual Results

stdout shows
"Failed to open file open test.log: errno 76"

Versions and Environment

Wasmtime version or commit: 12.0.1

Operating system: MacOS

Architecture: M1

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Aug 26 2023 at 13:04):

rbackhouse added the bug label to Issue #6914.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 26 2023 at 22:49):

pchickey assigned issue #6914 to pchickey.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 28 2023 at 15:32):

alexcrichton commented on issue #6914:

I poked around this a bit just now and I think there's a few things in play perhaps. I believe the "root cause" of this is that the entry point openfile generated doesn't initialize the Go runtime or wasi-libc. The tinygo tag you linked is using a was-libc from 2022 which requires explicit initialization to work for preopens, and by skipping this initialization by going straight to openfile that's why things aren't working. I've attempted to confirm this by having the adapter call _start then call openfile and that appears to get this working.

This means that I don't think the issue is in Wasmtime, but is instead on the tinygo side of things. One option would be to update wasi-libc since today's version doesn't require explicit initialization. Another option though would be to ensure that the exports generated by wit-bindgen initialize the Go runtime. I'm not sure what other Go details are involved for entering the runtime in a non-main situation.

In any case though I wasn't able to find any issues with Wasmtime itself or the adapter, so I'm going to close this as it's on the Wasmtime repo, but if you/others would prefer to keep discussion here while it's being fixed elsewhere I'm happy to reopen too.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 28 2023 at 15:32):

alexcrichton closed issue #6914:

I am unable to get file system calls to work from a tinygo based WASM component. All calls return "errno 76" "capabilities insufficient".

This originally started as a discussion on Zulip with Pat Hickey.
https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Problem.20with.20WasiCtxBuilder.2Epush_preopened_dir.20for.20component

Test Case

I've created a test case available at

https://github.com/rbackhouse/component-go-fs-test

The README details the prereqs and how to build and run.

Here are the wasm files built
testfswasm.zip

Steps to Reproduce

See README from https://github.com/rbackhouse/component-go-fs-test

Expected Results

stdout should show

""test.log created"

Actual Results

stdout shows
"Failed to open file open test.log: errno 76"

Versions and Environment

Wasmtime version or commit: 12.0.1

Operating system: MacOS

Architecture: M1

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Aug 28 2023 at 15:41):

rbackhouse commented on issue #6914:

Thanks Alex, I'll look into using an updated wasi-libc to see if that helps. I can continue the conversation on Zulip


Last updated: Dec 23 2024 at 12:05 UTC