Repository navigation
build: wasip1 is broken on wasmer runtime #59907
Description
This is a tracking issue for issues surrounding the use of the new wasip1 GOOS target on the wasmer Wasm runtime. We currently do not have a wasmer runner, but manual testing against the wasmer runtime has already yielded some results, namely, it is known that it exhibits a problem similar to wasmtime when it comes to opening directories (see #59583 (comment)).
This issue should not be considered done until we have a working wasmer runner and all tests are either passing or we have documented the failures which we cannot reasonably fix.
Currently known failing tests:
| Package | Test name | Error | Test log | Fixed |
|---|---|---|---|---|
| archive/tar | TestReader | open testdata/gnu.tar: Bad file number | Full log |
Activity
gopherbot commentedon May 9, 2023
Change https://go.dev/cl/493755 mentions this issue:
all: add wasmer wasip1 runnergopherbot commentedon May 9, 2023
Change https://go.dev/cl/493775 mentions this issue:
misc/wasm: add wasmer to wasip1 scriptmisc/wasm: add wasmer to wasip1 script
all: add wasmer wasip1 runner
johanbrandhorst commentedon May 9, 2023
The runner has been added and once the builders have been redeployed I will run a test run to see what errors we hit.
gopherbot commentedon May 16, 2023
Change https://go.dev/cl/495077 mentions this issue:
misc/wasm: test commitjohanbrandhorst commentedon May 18, 2023
The first runner test result against the
wasmerruntime is in, and it seems that it's refusing to do any file opens, instead erroring withBad file numberon practically all attempts. More investigation will be necessary. I have updated the table at the top.jakebailey commentedon May 18, 2023
I'm sure you are aware of this, but if you're looking to just check the current status of the runners, the build dashboard does contain links to the most recent builds per commit (wasip1 is all the way on the right), and should be a more convenient way to look up the current failures than CLs like CL 495077 that need the trybots run. That's how I've been watching things, at least.
johanbrandhorst commentedon May 18, 2023
Haha, I didn't actually know that it'd run our broken runners against tip, thanks! I'm still using the CLs to add extra debugging in some cases (like CL 491855) so I'll probably keep them around for myself anyway :).
gopherbot commentedon May 26, 2023
Change https://go.dev/cl/498616 mentions this issue:
misc/wasm: set PATH variable in execmisc/wasm: set PATH variable in exec
tliron commentedon Aug 23, 2023
For what it's worth, I have the same issue, but there is no error when running the same code using wasmtime. The issue seems specific to wasmer.
achille-roussel commentedon Aug 23, 2023
@syrusakbary maybe the wasmer team could help sort out the issue?
arjunmalhotra1 commentedon Mar 30, 2024
Hey @achille-roussel and @johanbrandhorst,
I will be happy to take a look at this if still unresolved and no one is working on this at the moment.
garciat commentedon Feb 11, 2025
I encountered this issue today with @wasmer/sdk@0.9.0 and Go 1.23.6.
However wasmer sets up its filesystem, Go is not able to read files from it and fails with
Bad file number.Gentle ping: @syrusakbary
iamrajiv commentedon Dec 7, 2025
Hi @johanbrandhorst, I checked the Wasmer code and found the issue.
Wasmer returns ENOTCAPABLE instead of EISDIR when attempting to open the root pre-open without directory rights. Go treats ENOTCAPABLE as a fatal error and does not retry, which results in the Bad file number error.
Specifically, in the Wasmer code here, it returns ENOTCAPABLE for Kind::Root. Changing this to EISDIR fixes the compatibility issue.
johanbrandhorst commentedon Dec 7, 2025
Great job, so the question then is whether this is Wasmer implementing the spec incorrectly or whether Go needs to handle this case differently. Has your research shed any light on which it is?
iamrajiv commentedon Jan 2, 2026
Hi @johanbrandhorst, sorry for the delay!
Based on my investigation, this is a Wasmer bug, not a Go issue. I've submitted a fix: wasmerio/wasmer#6009
There were actually three issues in Wasmer:
fd_prestat_getreported incorrectpr_name_len- Wasmer returnedname.len() + 1, including a null terminator in the length. The WASI spec sayspr_name_lenshould be the exact path length without null terminator. This caused Go to read preopen names like"/\x00"instead of"/", breaking path prefix matching entirely.fd_prestat_dir_namehad an off-by-one in buffer check - the conditionname.len() < path_lenwas too strict, returningEOVERFLOWfor exact-size buffers. Changed to<=.path_openreturned wrong error for root directory - Wasmer returnedENOTCAPABLEinstead ofEISDIRwhen opening root withoutO_DIRECTORY. Go's retry logic handlesEISDIRspecifically to retry with proper directory flags.iamrajiv commentedon Apr 1, 2026
@johanbrandhorst we can close this issue this has been fixed in the release https://github.com/wasmerio/wasmer/blob/main/CHANGELOG.md#700-rc1—23012026