runtime/coverage: inaccurate coverage with covermode=atomic on js/wasm

[Zxilly]

Go version

go version go1.22.4 windows/amd64

Output of go env in your module/workspace:

go env
set GO111MODULE=on
set GOARCH=wasm
set GOBIN=
set GOCACHE=C:\Users\12009\AppData\Local\go-build
set GOENV=C:\Users\12009\AppData\Roaming\go\env
set GOEXE=
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\zxilly\go\pkg\mod
set GONOPROXY=1
set GONOSUMDB=
set GOOS=js
set GOPATH=C:\Users\zxilly\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:/Users/zxilly/go/pkg/mod/golang.org/[email protected]
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Users\zxilly\go\pkg\mod\golang.org\t[email protected]\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.22.4
set GCCGO=gccgo
set GOWASM=
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=E:\Project\CS_Project\gsv\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-fPIC -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\zxilly\AppData\Local\Temp\go-build700005929=/tmp/go-build -gno-record-gcc-switches

What did you do?

Steps to Reproduction:

git clone https://github.com/Zxilly/go-size-analyzer.git
git checkout de09d207da04eb2633ec34a564e215946b069057
python scripts/tests.py --unit-wasm

Sorry I couldn't reproduce the problem in a smaller sample.

What did you see happen?

The script described above above will generate a unit.profile coverage file.

mode: atomic
github.com/Zxilly/go-size-analyzer/internal/result/result_js_wasm.go:5.42,7.31 2 1
github.com/Zxilly/go-size-analyzer/internal/result/result_js_wasm.go:7.31,9.3 1 21
github.com/Zxilly/go-size-analyzer/internal/result/result_js_wasm.go:11.2,18.3 2 1

with go tool cover -html="unit.profile", got a page

None of the statements after append are computed into coverage. The programme didn't crash either, because the result in test turned out to be success.

What did you expect to see?

Coverage should be able to correctly report all lines and files that are run.

[gabyhelp]

Similar Issues

• cmd/go: test -cover reports 100.0% without full coverage #39168
• cmd/distpack: misc/wasm folder should be kept in the toolchain package #68024
• runtime/coverage: coverage from other binaries is not collected in tests #60182
• cmd/go: test with coverage unexpect fail #43242
• cmd/go: test -cover should print the total module coverage #49917

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[Zxilly]

I confirmed this error exists for go-tip go version devel go1.23-8f5c6904b6 Sun Jun 16 23:08:08 2024 +0000 windows/amd64

[Zxilly]

The wasm wrapper I used is https://github.com/golang/go/blob/master/misc/wasm/go_js_wasm_exec

[Zxilly]

@thanm Can you check this issue?

[Zxilly]

@seankhliao I've test against set, count and atomic, none of them works.

[seankhliao]

your reproduction step uses too many unnecessary dependencies like python.
all it does is:

export GOARCH=wasm
export GOOS=js
export PATH="$PATH:$(go env GOROOT)/misc/wasm"
go test -v -cover -covermode atomic -coverprofile unit.profile ./internal/result
go tool cover -html unit.profile

and as far as I can tell, it reproduces only with atomic or count, not set.

[Zxilly]

Yes, covermode set works correctly.

[thanm]

Not sure if I see a bug here, things look like they are working as intended. First screendump from the HTML report with atomic mode:

Note the color of "low coverage" on the left. This shade is chosen (I presume) to be slightly above the gray value of "not tracked". Now here's a screendump of the func body:

I invite you to squint carefully and compare the shade of the first line ("MarshallJavaScript") with the shade of the second line ("var sections []any"). The color of the first line corresponds to that of "untracked" from the legend, and the color of the second line corresponds to "low coverage" from the legend. Note that "low" does not mean zero.

With that said, it is clear that the status quo is confusing. Maybe we need to choose a different color scheme, something that makes it easier to tell the difference between "low" and "zero" more reliably. Let me know what you think.

[Zxilly]

Sorry, I realise this may have been a mistake.
The error should be caused by codecov and not gc, I will report it to them.