In CL 660696, we made the linker to choose the symbol of the
larger size in case there are multiple contentless declarations of
the same symbol. We also made it emit an error in the case that
there are a contentless declaration of a larger size and a
definition with content of a smaller size. In this case, we should
choose the definition with content, but the code accesses it
through the declaration of the larger size could fall into the
next symbol, potentially causing data corruption. So we disallowed
it.
There is one spcial case, though, that some code uses a linknamed
variable declaration to reference a function in assembly, in order
to take its address. The variable is often declared as uintptr.
The function symbol is the definition, which could sometimes be
shorter. This would trigger the error case above, causing existing
code failing to build.
This CL allows it as a special case. It is still not safe to
access the variable's content. But it is actually okay to just
take its address, which the existing code often do.
Fixes#73617.
Change-Id: I467381bc5f6baa16caee6752a0a824c7185422f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/676636
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
- Add section headings to make the section easier to read.
- Reorder features to better reflect their impact and importance.
- Tweak some awkward wording here and there.
Change-Id: If72c526f4b3a26a7a4584d6c59857db02c0c1338
Reviewed-on: https://go-review.googlesource.com/c/go/+/676818
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit generated by update.bash.
For #22487.
Change-Id: If4132dc12296b23b85a221bffdb1b854d0332010
Reviewed-on: https://go-review.googlesource.com/c/go/+/676855
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix a bug in CL 672396, where we add FILE_FLAG_OPEN_REPARSE_POINT to
the attributes passed to CreateFile, but then overwrite the attributes
with FILE_ATTRIBUTE_READONLY when opening a file with a read-only
permissions mode.
For #73702
Change-Id: I6c10bf470054592bafa031732585fc3155c61341
Reviewed-on: https://go-review.googlesource.com/c/go/+/676655
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Cleanup functions and finalizers must not run in a synctest bubble.
If they did, a function run by the GC at an unpredictable time
could unblock a bubble that synctest believes is durably
blocked.
Add a test verifying that cleanups and finalizers are always
run by non-bubbled goroutines. (This is already the case because
we never add system goroutines to a bubble.)
For #67434
Change-Id: I5a48db2b26f9712c3b0dc1f425d99814031a2fc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/675257
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
When creating a new *ir.Name or *ir.LinksymOffsetExpr to represent
a composite literal stored in the read-only data section, we should
use the original type of the expression that was found via
ir.ReassignOracle.StaticValue. (This is needed because the StaticValue
method can traverse through OCONVNOP operations to find its final
result.)
Otherwise, the compilation may succeed, but the linker might erroneously
conclude that a type is not used and prune an itab when it should not,
leading to a call at execution-time to runtime.unreachableMethod, which
throws "fatal error: unreachable method called. linker bug?".
The tests exercise both the case of a zero value struct literal that
can be represented by the read-only runtime.zeroVal, which was the case
of the simplified example from #73888, and also modifies that example to
test the non zero value struct literal case.
This CL makes two similar changes for those two cases. We can get either
of the tests we are adding to fail independently if we only make
a single corresponding change.
Fixes#73888
Updates #71359
Change-Id: Ifd91f445cc168ab895cc27f7964a6557d5cc32e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/676517
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This adds a test which validates the traces generated by the execution
tracer and the flight recorder depending on the order where they are
stopped and started. This test uncovered that under certain
circumstances, the traces which were produced would possibly be
missing the trace header. All traces have the trace headers included
now. Clock snapshot checks have been disabled for Windows and WASM.
Change-Id: I5be719d228300469891fc56817fbce4ba5453fff
Reviewed-on: https://go-review.googlesource.com/c/go/+/675975
Auto-Submit: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Before this change, go get didn't have support for the work pattern. The
work pattern is new in Go 1.25 and evaluates to the packages in the work
(also called main) modules. 'go get work' would cause a panic because
'work' would be incorrectly considered a path pattern and then queryPath
would would try to query a metapackage pattern (resulting in the
internal error panic). This change properly supports the work pattern in
go get.
It's pretty simple: First, we need to seprate the work pattern from the
other patterns. Then in performWorkQueries, which maps queries to the
modules that satisfy them, we return the single main module because by
definition the work pattern is the set of packages in the work modules,
and go get always runs in single module mode. (The exception is when the
work module contains no packages, in which case we report a warning, and
return no candidates because nothing is needed to resolve nothing).
The rest of the work is already done by loading the packages matching
the query and finding missing imports in the call to
findAndUpgradeImports in runGet.
Change-Id: I3c4610878b3d930a1d106cc59d9a0be194d966cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/675895
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: I91c03f455fff8e4078f3297ea357cd1e1dd09f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/676536
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adds a benchmark of FileSet.Position, the lookup
operation, and the new AddExistingFiles. It is evident
that its behavior is quadratic in important cases:
(Apple M1)
BenchmarkFileSet_AddExistingFiles/sequence-8 3 362768139 ns/op
Change-Id: I256fdc776135e1924666d127afb37dacbefc860f
Reviewed-on: https://go-review.googlesource.com/c/go/+/675875
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
(More symbols that belong to the ast.Object deprecation.)
Fixes#73088Fixes#7124
Updates #52463
Updates #71122
Change-Id: I10e3ef35b587da2f3f0a65e9154e33bd53e7a093
Reviewed-on: https://go-review.googlesource.com/c/go/+/674176
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
cleanupQueue.Flush is reachable from mallocgc via sweepAssist. Normally
allp will continue all valid Ps, but procresize itself increases the
size of allp and then allocates new Ps to place in allp. If we get
perfectly unlucky, the new(p) allocations will complete sweeping and
cleanupQueue.Flush will dereference a nil pointer from allp. Avoid this
by skipping nil Ps.
I've looked through every other use of allp and none of them appear to
be reachable from procresize.
Change-Id: I6a6a636cab49ef268eb8fcd9ff9a96790d9c5685
Reviewed-on: https://go-review.googlesource.com/c/go/+/676515
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The two bugs are very minor:
- We were trying to set the ConnectionState CurveID field even if the
RSA key exchange was in use
- We were sending the wrong alert from TLS 1.2 clients if none of the
certificate signature algorithms were supported
Change-Id: I6a6a46564f5a9f1a5d44e54fc59a650118ad67d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/675918
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Id7489247e9bdd413f82fdf5a70197856c47abfb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/674336
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Change-Id: I8451179bc0fa88b7e60afbc6fd9e06a22a94f3aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/673835
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
We mention that already in Cloner docs, but to be consistent, also
mention that in Hash.
Change-Id: Iee33d545662b7054973666bd45998a37f3037a51
Reviewed-on: https://go-review.googlesource.com/c/go/+/675915
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Adds TODO for replacement of runtime.SetFinalizer.
Fixes#70907
Change-Id: Ic009018a93ccc46a776ae34afac44635d2340cbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/638557
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
runtime.traceClockNow returns a (named) uint64. Make the declaration in
runtime/trace match this type.
Change-Id: I6a6a636ce3596cbc6fc5bac3590703b7b4839c4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/675976
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is the output of relnote -goroot=... todo,
with each todo in a comment, followed by summary
text from the issue and perhaps the CL, lightly
processed into markdown.
For #71661.
Change-Id: I855c4c4ee02491b5b6113822baf69dbafb4e54ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/675877
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also, fix a minor typo in ServeMux.Handle and ServeMux.HandleFunc.
Change-Id: I6a6a46565719104cb8f2484daf0e39f35b55a078
Reviewed-on: https://go-review.googlesource.com/c/go/+/675835
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change fixes the flaky test which expects setting SetMinAge to a
small ammount. It expects two sync events but should realistically
expect up to 3.
Change-Id: Ibd02fe55ebca99eb880025eb968fcebae9cb09c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/675597
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I2133e3c62b4de0cec08eeb120d593c644643a62c
Reviewed-on: https://go-review.googlesource.com/c/go/+/675755
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Also mention the bisect tool and flag used to track down
incorrect uses.
Change-Id: Id36a236e1bb2733b8611b22a5b16916e7d9f5522
Reviewed-on: https://go-review.googlesource.com/c/go/+/666075
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 674655 modified the checkfinalizers test to spin looking for an
appropriate address to trip the detector, but this doesn't work with
ASAN or in race mode, which both disable the tiny allocator.
Fixes#73834.
Change-Id: I27416da1f29cd953271698551e9ce9724484c683
Reviewed-on: https://go-review.googlesource.com/c/go/+/675395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 585399 fixed an initialization loop during IR contruction that
involving alias type, by avoiding publishing alias declarations until
the RHS type expression has been constructed.
There's an assertion to ensure that the alias's type must be the same
during the initialization. However, that assertion is too strict, since
we may construct different instances of the same type, if the type is an
instantination of generic type.
To fix this, we could use types.IdenticalStrict to ensure that these
types matching exactly.
Updates #66873.
Updates #73309.
Change-Id: I2559bed37e21615854333fb1057d7349406e6a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/668175
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
This change fixes a bug that was introduced in CL 675155. Instead of
doing the two step download and run with GOPROXY=off, do the run with
GOPROXY=<download cache>:$GOPROXY, so that we use the previously
downloaded version of pkgsite as the latest.
Fixes#73833
Change-Id: I8803426498ab026602805d6448a130eb11458c99
Reviewed-on: https://go-review.googlesource.com/c/go/+/675576
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts commit 988eb0d11e.
Reason for revert: breaks viewing documentation for unfetched modules
For #73833
Change-Id: I89bc459e820c85e96837d1707058501488a14eef
Reviewed-on: https://go-review.googlesource.com/c/go/+/675575
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
When transforming for loop variables, the compiler does roughly
following steps:
(1) prebody = {z := z' for z in leaked}
...
(4) init' = (init : s/z/z' for z in leaked)
However, the definition of z is not updated to `z := z'` statement,
causing ReassignOracle incorrectly use the new init statement with z'
instead of z, trigger the ICE.
Fixing this by updating the correct/new definition statement for z
during the prebody initialization.
Fixes#73823
Change-Id: Ice2a6741be7478506c58f4000f591d5582029136
Reviewed-on: https://go-review.googlesource.com/c/go/+/675475
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently weak pointers break in sbrk mode. We can just use the immortal
weak handle map for weak pointers in this case, since nothing is ever
freed.
Fixes#69729.
Change-Id: Ie9fa7e203c22776dc9eb3601c6480107d9ad0c99
Reviewed-on: https://go-review.googlesource.com/c/go/+/674656
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
unique.Make always copies strings passed into it, so it's safe to not
copy byte slices converted to strings either. Handle this just like map
accesses with string(b) as keys.
This CL only handles unique.Make(string(b)), not nested cases like
unique.Make([2]string{string(b1), string(b2)}); this could be done in a
followup CL but the map lookup code in walk is sufficiently different
than the call handling code that I didn't attempt it. (SSA is much
easier).
Fixes#71926
Change-Id: Ic2f82f2f91963d563b4ddb1282bd49fc40da8b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/672135
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Hash.float64 and btoi helper functions are used only in the purego
version. Move them to the build tagged file.
Change-Id: I57f9a48966573ab0aee1de759eeddd2331967870
Reviewed-on: https://go-review.googlesource.com/c/go/+/675158
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, hash/maphash.Comparable escapes its parameter if it
contains non-string pointers, but does not escape strings or types
that contain strings but no other pointers. This is achieved by a
compiler intrinsic.
unique.Make does something similar: it stores its parameter to a
central map, with strings cloned. So from the escape analysis's
perspective, the non-string pointers are passed through, whereas
string pointers are not. We currently cannot model this type of
type-dependent data flow directly in Go. So we do this with a
compiler intrinsic. In fact, we can unify this and the intrinsic
above.
Tests are from Jake Bailey's CL 671955 (thanks!).
Fixes#73680.
Change-Id: Ia6a78e09dee39f8d9198a16758e4b5322ee2c56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/675156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
This was the first CL in a series of CLs aimed at reducing
how often interface arguments escape for the print functions in fmt.
This CL makes some small improvements to the escape analysis logging.
Here is a sample snippet of the current -m=2 logs:
./print.go:587:7: parameter p leaks to {heap} with derefs=0:
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).printArg(p, err, 'v') (call parameter) at ./print.go:613:13
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).handleMethods(p, verb) (call parameter) at ./print.go:749:22
[..]
If we attempt to tease apart some reasons why the -m=2 logs can be
challenging to understand for the uninitiated:
- The "flow" lines are very useful, but contain more-or-less abstracted
pseudocode. The "from" lines most often use actual code. When first
looking at the logs, that distinction might not be apparent, which can
result in looking back to the original code to hunt for pseudocode
that doesn't exist there. (The log example shows 'p = p', but there is
no 'p = p' in the original source).
- Escape analysis can be most interesting with inlining, but that can
result in seeing overlapping short variable names (e.g., p, b, v...).
- The directionality of the "flow" lines might not be obvious,
including whether they build top-to-bottom or bottom-to-top.
- The use of '{' and '}' in the -m=2 logs somewhat intersects with Go
literals (e.g., if the log says "{temp}", an initial thought might
be that represents some temp inside of some Go literal).
- And of course, escape analysis itself is subtle.
This CL:
- Adds the function name to the first -m=2 line to provide more context
and reduce how often the reader needs to lookup line numbers.
- Uses the Unicode left arrow '←' rather than '=' on the flow lines
to make it clearer that these lines are abstracted away from the
original Go code and to help the directionality jump out.
In the future, we can consider changing "{heap}", "{temp}",
"{storage for foo}" to something else, but we leave them as is for now.
Two examples with the modifications:
./f1.go:3:9: parameter inptr leaks to outptr for func1 with derefs=0:
./f1.go:3:9: flow: localptr ← inptr:
./f1.go:3:9: from localptr := inptr (assign) at ./f1.go:4:11
./f1.go:3:9: flow: outptr ← localptr:
./f1.go:3:9: from return localptr (return) at ./f1.go:5:2
./b.go:14:20: []byte{...} escapes to heap in byteOrderExample:
./b.go:14:20: flow: b ← &{storage for []byte{...}}:
./b.go:14:20: from []byte{...} (spill) at ./byteorder.go:14:20
./b.go:14:20: from b := []byte{...} (assign) at ./byteorder.go:14:11
./b.go:14:20: flow: <heap> ← b:
./b.go:14:20: from byteOrder.Uint32(b) (call parameter) at ./byteorder.go:15:32
These changes only affect the -m=2 output and leave the -m=1 output
as is.
Updates #8618
Updates #62653
Change-Id: Ic082a371c3d3fa0d8fd8bfbe4d64ec3e1e53c173
Reviewed-on: https://go-review.googlesource.com/c/go/+/524937
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This change adds the flight recorder to the trace package.
Flight recording is a technique in which trace data is kept
in a circular buffer and can be flushed upon request. The
implementation will be added in follow-up CLs.
The flight recorder has already been implemented inside of the
golang.org/x/exp/trace package. This copies the current implementation
and modifies it to work within the runtime/trace package.
The changes include:
This adds the ability for multiple consumers (both the execution
tracer and the flight recorder) to subscribe to tracing events. This
change allows us to add multiple consumers without making major
modifications to the runtime. Future optimizations are planned
for this functionality.
This removes the use of byte readers from the process that
parses and processes the trace batches.
This modifies the flight recorder to not parse out the trace
clock frequency, since that requires knowledge of the format that's
unfortunate to encode in yet another place. Right now, the trace clock
frequency is considered stable for the lifetime of the program, so just
grab it directly from the runtime.
This change adds an in-band end-of-generation signal to the internal
implementation of runtime.ReadTrace. The internal implementation is
exported via linkname to runtime/trace, so the flight recorder can
identify exactly when a generation has ended. This signal is also useful
for ensuring that subscribers to runtime trace data always see complete
generations, by starting or stopping data streaming only at generation
boundaries.
For #63185
Change-Id: I5c15345981a6bbe9764a3d623448237e983c64ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/673116
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Use the non-experimental Test function.
As a bonus, this lets us drop the hacks we were doing to support
t.Cleanup inside bubbles.
Change-Id: I070624e1384494e9d5fcfee594cfbb7680c1beda
Reviewed-on: https://go-review.googlesource.com/c/go/+/675315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Add a new Attr method to testing.TB that emits a test attribute.
An attribute is an arbitrary key/value pair.
Fixes#43936
Change-Id: I7ef299efae41f2cf39f2dc61ad4cdd4c3975cdb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/662437
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
When a TLS 1.3 client processes the server's encryptedExtensionsMsg it
should reject instances that contain duplicate extension types.
RFC 8446 §4.2 says:
There MUST NOT be more than one extension of the same type in a given
extension block.
This update matches enforcement done in the client hello unmarshalling,
but applied to the TLS 1.3 encrypted extensions message unmarshalling.
Making this change also allows enabling the
DuplicateExtensionClient-TLS-TLS13 BoGo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/673757
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Previously if instances of the handshakeMessage interface returned false
from unmarshal(), indicating an umarshalling error, the crypto/tls
package would emit an unexpected_message alert. This commit changes to
use a decode_error alert for this condition instead.
The usage-pattern of the handshakeMessage interface is that we switch on
the message type, invoke a specific concrete handshakeMessage type's
unmarshal function, and then return it to the caller on success. At this
point the caller looks at the message type and can determine if the
message was unexpected or not. If it was unexpected, the call-sites emit
the correct error for that case. Only the caller knows the current
protocol state and allowed message types, not the generic handshake
decoding logic.
With the above in mind, if we find that within the unmarshal logic for
a specific message type that the data we have in hand doesn't match the
protocol syntax we should emit a decode_error. An unexpected_message
error isn't appropriate because we don't yet know if the message is
unexpected or not, only that the message can't be decoded based on the
spec's syntax for the type the message claimed to be.
Notably one unit test, TestQUICPostHandshakeKeyUpdate, had to have its
test data adjusted because it was previously not testing the right
thing: it was double-encoding the type & length prefix data for a key
update message and expecting the QUIC logic to reject it as an
inappropriate post-handshake message. In reality it was being rejected
sooner as an invalid key update message from the double-encoding and
this was masked by the previous alert for this condition matching the
expected alert.
Finally, changing our alert allows enabling a handful of BoGo tests
related to duplicate extensions of the form
"DuplicateExtension[Server|Client]-TLS-[TLS1|TLS11|TLS12|TLS13]". One
test remains skipped (DuplicateExtensionClient-TLS-TLS13), as it
requires additional follow-up.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/673738
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
