| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix up the coverage testpoint TestIssue59563TruncatedCoverPkgAll
to avoid spurious failures due to racy behavior. Specifically,
we are only interested in verifying coverage for the larger
function of the two in the test package (the smaller one is only
there to trigger additional function registrations while the
test is finalizing the cov data).
Updates #59867.
Updates #59563.
Change-Id: Ibfbbcbf68e0ad7a4d9606cbcfc69d140375c7b87
Reviewed-on: https://go-review.googlesource.com/c/go/+/492175
Run-TryBot: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Change-Id: Idea3e6ca6e62bd5a5ff6e6d5c3f39efb7628f0ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/489635
Run-TryBot: Michael Pratt <mpratt@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was found by running `git grep 'fmt.Sprintf("%d",' | grep -v test | grep -v vendor`
And this was automatically fixed with gotiti https://github.com/catenacyber/gotiti
and using unconvert https://github.com/mdempsky/unconvert
to check if there was (tool which fixed another useless cast)
Change-Id: I023926bc4aa8d51de45f712ac739a0a80145c28c
GitHub-Last-Rev: 1063e32e5b69b6f9bb17673887b8c4ebe5be8fe4
GitHub-Pull-Request: golang/go#59144
Reviewed-on: https://go-review.googlesource.com/c/go/+/477675
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
| |
|
|
|
|
|
|
|
|
| |
Change-Id: I18bb87bfdea8b6d7994091ced5134aa2549f221e
Reviewed-on: https://go-review.googlesource.com/c/go/+/472476
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing runtime/coverage API set includes a "ClearCounters()"
function that zeros out the counter values in a running process so as
enable capturing of a coverage profile from a specific execution time
segment. Calling this function is only permitted if the program is
built with "-covermode=atomic", due (in part) to concerns about
processors with relaxed memory models in which normal stores can be
reordered.
In the bug in question, a test that stresses a different set of
counter-related APIs was hitting an invalid counter segment when
running on a machine (ppc64) which does indeed have a relaxed memory
consistency model.
From a post-mortem examination of the counter array for the harness
from the ppc64 test run, it was clear that the thread reading values
from the counter array was seeing the sort of inconsistency that could
result from stores being reordered (specifically the prolog
"packageID" and "number-of-counters" stores).
To preclude the possibility of future similar problems, this patch
extends the "atomic mode only" restriction from ClearCounters to the
other APIs that deal with counters (WriteCounters, WriteCountersDir).
Fixes #56197.
Change-Id: Idb85d67a84d69ead508e0902ab46ab4dc82af466
Reviewed-on: https://go-review.googlesource.com/c/go/+/463695
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When walking through the set of coverage data files generated from a
"go test -cover" run, it's possible to encounter pods (clumps of data
files) that were generated by a run from an instrumented Go tool (for
example, cmd/compile). Add a guard to the test reporting code to
ensure that it only processes files created by the currently running
test.
Fixes #57924.
Change-Id: I1bb7dce88305e1088162e3cb1df628486ecee1c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/462756
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The processPod() helper (invoked by processCoverTestDir, which is in
turn called by _testmain.go) was opening and reading counter data
files, but never closing them. Add a call to close the files after
they have been read.
Fixes #57407.
Change-Id: If9a489f92e4bab72c5b2df8697e14420a6f7b8f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/458835
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a buglet in cmd/cover in how we handle package name/path for the
"go build -o foo.exe *.go" and "go run *.go" cases.
The go command assigns a dummy import path of "command-line-arguments"
to the main package built in these cases; rather than expose this
dummy to the user in coverage reports, the cover tool had a special
case hack intended to rewrite such package paths to "main". The hack
was too general, however, and was rewriting the import path of all
packages with (p.name == "main") to an import path of "main". The hack
also produced unexpected results for cases such as
go test -cover foo.go foo_test.go
This patch removes the hack entirely, leaving the package path for
such cases as "command-line-arguments".
Fixes #57169.
Change-Id: Ib6071db5e3485da3b8c26e16ef57f6fa1712402c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456237
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more skips if short mode testing, since some of these tests
still seem to be timing out on smaller and more underpowered
builders.
Updates #56197.
Change-Id: I469d9fd3a6be5602243234562fa3fe6263968b56
Reviewed-on: https://go-review.googlesource.com/c/go/+/443376
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes up a bug in the inliner's special case code for
coverage counter updates, which was not properly working for
-covermode=atomic compilations.
Updates #56044.
Change-Id: I9e309312b123121c3df02862623bdbab1f6c6a4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/441858
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use shorter more Go-like names for the new APIs being added in the
runtime/coverage package for writing coverage data under user control
from server programs. Old names were a bit too clunky/verbose.
Updates #51430.
Change-Id: Ifdd5b882a88613c7c4342b40ed93b58547483c77
Reviewed-on: https://go-review.googlesource.com/c/go/+/438503
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Read counters using atomic ops so as to avoid problems with the race
detector if a goroutine happens to still be executing at the end of a
test run when we're writing out counter data. In theory we could guard
the atomic use on the counter mode, but it's better just to do it in
all cases, leaves us with a simpler implementation.
Fixes #56006.
Change-Id: I81c2234b5a1c3b00cff6c77daf2c2315451b7f6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/438256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In TestCoverageApis/emitToNonexistentDir there is a list of error
messages to match when a nonexistent directory is opened. The list
has message text only for Unix and Windows. Add the corresponding
text for Plan 9.
Fixes #55983
Change-Id: Id32130300cb02394b319e1aeb1229ee147b4afb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/437557
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add hooks/apis to support writing of coverage counter data and
meta-data under user control (from within an executing "-cover"
binary), so as to provide a way to obtain coverage data from programs
that do not terminate. This patch also adds a hook for clearing the
coverage counter data for a running program, something that can be
helpful when the intent is to capture coverage info from a specific
window of program execution.
Updates #51430.
Change-Id: I34ee6cee52e5597fa3698b8b04f1b34a2a2a418f
Reviewed-on: https://go-review.googlesource.com/c/go/+/401236
Reviewed-by: David Chase <drchase@google.com>
|
| |
|
|
|
|
|
|
|
| |
Add a testpoint to cover support routines used to help
implement "go test -cover".
Change-Id: Ic28bf884a4e0d2c0a6d8fd04fc29c0c949227f21
Reviewed-on: https://go-review.googlesource.com/c/go/+/432315
Reviewed-by: Bryan Mills <bcmills@google.com>
|
|
|
This patch fleshes out the runtime support for emitting coverage data
at the end of a run of an instrumented binary. Data is emitted in the
form of a pair of files, a meta-out-file and counter-data-outfile,
each written to the dir GOCOVERDIR. The meta-out-file is emitted only
if required; no need to emit again if an existing meta-data file with
the same hash and length is present.
Updates #51430.
Change-Id: I59d20a4b8c05910c933ee29527972f8e401b1685
Reviewed-on: https://go-review.googlesource.com/c/go/+/355451
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
|
