agnivade/wasmbrowsertest

error generating coverage report

Closed this issue · 7 comments

mlctrez commented

First off 😎 thanks for your work on this!

When a recent version of go I'm getting an error when generating code coverage:

error generating coverage report: output directory "/tmp/go-build888418937/b001/gocoverdir" inaccessible (err: stat /tmp/go-build888418937/b001/gocoverdir: not implemented on js); no coverage data written

go test . works with later versions of go but breaks when adding -cover

This repository contains my test case wbtexample

When running with go1.18.4 there are no errors.
shell script

When running with go1.20.7 I get the error generating coverage.
shell script

I've added logging statements in github.com/agnivade/wasmbrowsertest and have tracked it down to a non-zero exit code at main.go

I'm using google chrome 116.0.5845.96 on Ubuntu 22.04.3 LTS if that matters.

agnivade commented

Thanks, yes there seems to be some issues with Go 1.20 onwards. Even CI fails with 1.20. I need to spend some time to take a look.

We also need to bump the version in go.mod file.

cc @JohnStarich in case you want to take a look.

mlctrez commented

This appears to be caused by design/51430-revamp-code-coverage

Here's the location the stat call occurs:
https://github.com/golang/go/blob/39957b5d89fec8bc3a79f4a982452c6e3d5b3ad3/src/runtime/coverage/emit.go#L398-L405

Passing an env GOEXPERIMENT=none works with go 1.20 and later as a temp workaround.

agnivade commented

Nice catch! Looks like we need to do a bit of work to support fs.stat.

mlctrez commented

Looked into what it would take to support this. As it turns out, it is much larger than just fs.stat.

The new coverage code is accessing /tmp/go-build<nnn..>/b<nnn>/gocoverdir which appears to be created by the go tooling before calling into wasmbrowsertest. The new coverage code then tries to write, rename, list, and read files in this directory. So the fs.xxxx calls so far are stat, rename, fstat, readdir, lstat, and read.

I was thinking of other options, like the native filesystem api, but came across your comment forwarding all file-system calls to the webserver so I'm now thinking that as well.

If you have not already started on the forwarding fs calls route, I can take a look at it.

agnivade commented

Thanks for digging deep. Yes, the fs API forwarding to the webserver would be a much more robust solution. This would also finally unblock any filesystem read/write related tests, which would fix golang/go#26051!

  • 👍1
mlctrez commented

Dug a bit deeper, ended up digging a tunnel, then found the light at the end of it. 😃

I have not tested this extensively but it appears to be fairly solid. I'll add more to it in the next few days but wanted to share it for whoever is interested. It definitely needs more testing on non-unix platforms.

JohnStarich commented

This is awesome, thanks @mlctrez!

  • 👍1