mirror of
https://github.com/golang/go
synced 2024-09-29 05:14:29 -06:00
39957b5d89
This patch revises the way coverage counter data writing takes place to avoid problems where useful counter data (for user-written functions) is skipped in favor of counter data from stdlib functions that are executed "late in the game", during the counter writing process itself. Reading counter values from a running "--coverpkg=all" program is an inherently racy operation; while the the code that scans the coverage counter segment is reading values, the program is still executing, potentially updating those values, and updates can include execution of previously un-executed functions. The existing counter data writing code was using a two-pass model (initial sweep over the counter segment to count live functions, second sweep to actually write data), and wasn't properly accounting for the fact that the second pass could see more functions than the first. In the bug in question, the first pass discovered an initial set of 1240 functions, but by the time the second pass kicked in, several additional new functions were also live. The second pass scanned the counter segment again to write out exactly 1240 functions, but since some of the counters for the newly executed functions were earlier in the segment (due to linker layout quirks) than the user's selected function, the sweep terminated before writing out counters for the function of interest. The fix rewrites the counter data file encoder to make a single sweep over the counter segment instead of using a two-pass scheme. Fixes #59563. Change-Id: I5e908e226bb224adb90a2fb783013e52deb341da Reviewed-on: https://go-review.googlesource.com/c/go/+/484535 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> |
||
---|---|---|
.. | ||
archive | ||
arena | ||
bufio | ||
builtin | ||
bytes | ||
cmd | ||
compress | ||
container | ||
context | ||
crypto | ||
database/sql | ||
debug | ||
embed | ||
encoding | ||
errors | ||
expvar | ||
flag | ||
fmt | ||
go | ||
hash | ||
html | ||
image | ||
index/suffixarray | ||
internal | ||
io | ||
log | ||
maps | ||
math | ||
mime | ||
net | ||
os | ||
path | ||
plugin | ||
reflect | ||
regexp | ||
runtime | ||
slices | ||
sort | ||
strconv | ||
strings | ||
sync | ||
syscall | ||
testdata | ||
testing | ||
text | ||
time | ||
unicode | ||
unsafe | ||
vendor | ||
all.bash | ||
all.bat | ||
all.rc | ||
bootstrap.bash | ||
buildall.bash | ||
clean.bash | ||
clean.bat | ||
clean.rc | ||
cmp.bash | ||
go.mod | ||
go.sum | ||
make.bash | ||
make.bat | ||
Make.dist | ||
make.rc | ||
race.bash | ||
race.bat | ||
README.vendor | ||
run.bash | ||
run.bat | ||
run.rc |
Vendoring in std and cmd ======================== The Go command maintains copies of external packages needed by the standard library in the src/vendor and src/cmd/vendor directories. There are two modules, std and cmd, defined in src/go.mod and src/cmd/go.mod. When a package outside std or cmd is imported by a package inside std or cmd, the import path is interpreted as if it had a "vendor/" prefix. For example, within "crypto/tls", an import of "golang.org/x/crypto/cryptobyte" resolves to "vendor/golang.org/x/crypto/cryptobyte". When a package with the same path is imported from a package outside std or cmd, it will be resolved normally. Consequently, a binary may be built with two copies of a package at different versions if the package is imported normally and vendored by the standard library. Vendored packages are internally renamed with a "vendor/" prefix to preserve the invariant that all packages have distinct paths. This is necessary to avoid compiler and linker conflicts. Adding a "vendor/" prefix also maintains the invariant that standard library packages begin with a dotless path element. The module requirements of std and cmd do not influence version selection in other modules. They are only considered when running module commands like 'go get' and 'go mod vendor' from a directory in GOROOT/src. Maintaining vendor directories ============================== Before updating vendor directories, ensure that module mode is enabled. Make sure that GO111MODULE is not set in the environment, or that it is set to 'on' or 'auto'. Requirements may be added, updated, and removed with 'go get'. The vendor directory may be updated with 'go mod vendor'. A typical sequence might be: cd src go get golang.org/x/net@latest go mod tidy go mod vendor Use caution when passing '-u' to 'go get'. The '-u' flag updates modules providing all transitively imported packages, not only the module providing the target package. Note that 'go mod vendor' only copies packages that are transitively imported by packages in the current module. If a new package is needed, it should be imported before running 'go mod vendor'.