There's a "lib/time" sub-section in the Go 1.12 relase notes that
points to a non-existent golang.org/pkg/lib/time page.
The note is about a change in the tz database in the src/lib/time
directory, but the section's title (and the link) should probably just
refer to the time package.
Change-Id: Ibf9dacd710e72886f14ad0b7415fea1e8d25b83a
Reviewed-on: https://go-review.googlesource.com/c/164977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 0dc6256540)
Reviewed-on: https://go-review.googlesource.com/c/164964
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
With stack objects, when we scan the stack, it scans defers with
tracebackdefers, but it seems to me that tracebackdefers doesn't
include the func value itself, which could be a stack allocated
closure. Scan it explicitly.
Alternatively, we can change tracebackdefers to include the func
value, which in turn needs to change the type of stkframe.
Updates #30453.
Fixes#30470.
Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b
Reviewed-on: https://go-review.googlesource.com/c/164118
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 4f4c2a79d4)
Reviewed-on: https://go-review.googlesource.com/c/164629
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If GOCACHE is set but is not an absolute path, we cannot build.
And GOCACHE=off also returns the error message "build cache is
disabled by GOCACHE=off".
Fixes#30493
Change-Id: I24f64bc886599ca0acd757acada4714aebe4d3ae
Reviewed-on: https://go-review.googlesource.com/c/164200
Run-TryBot: Baokun Lee <nototon@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 13d24b685a)
Reviewed-on: https://go-review.googlesource.com/c/164717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Revert CL 137055, which changed Clean("\\somepath\dir\") to return
"\\somepath\dir" on Windows. It's not entirely clear this is correct,
as this path is really "\\server\share\", and as such the trailing
slash may be the path on that share, much like "C:\". In any case, the
change broke existing code, so roll it back for now and rethink for 1.13.
Updates #27791
Updates #30307
Change-Id: I69200b1efe38bdb6d452b744582a2bfbb3acbcec
Reviewed-on: https://go-review.googlesource.com/c/163077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 153c0da89b)
Reviewed-on: https://go-review.googlesource.com/c/163078
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Current assembler reports error when it assembles
"TSTW $1689262177517664, R3", but go1.11 was building
fine.
Fixes#30334
Change-Id: I9c16d36717cd05df2134e8eb5b17edc385aff0a9
Reviewed-on: https://go-review.googlesource.com/c/163259
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
(cherry picked from commit 2ef8abb41f)
Reviewed-on: https://go-review.googlesource.com/c/163419
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Using go get prevents the failure case of when the
user doesn't have the repo on their machine.
Change-Id: I9c1174087728b5b06b578b0d52df6eeb7e8c7a3c
Reviewed-on: https://go-review.googlesource.com/c/163718
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2f9728aacd)
Reviewed-on: https://go-review.googlesource.com/c/163719
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
A recent change to fix stacktraces for inlined functions
introduced a regression on ppc64le when compiling position
independent code. That happened because ginsnop2 was called for
the purpose of inserting a NOP to identify the location of
the inlined function, when ginsnop should have been used.
ginsnop2 is intended to be used before deferreturn to ensure
r2 is properly restored when compiling position independent code.
In some cases the location where r2 is loaded from might not be
initialized. If that happens and r2 is used to generate an address,
the result is likely a SEGV.
This fixes that problem.
Fixes#30283
Change-Id: If70ef27fc65ef31969712422306ac3a57adbd5b6
Reviewed-on: https://go-review.googlesource.com/c/163337
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 2d3474043c)
Reviewed-on: https://go-review.googlesource.com/c/163717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 154057 adds guards agaist out-of-bound reads from readonly
constants. It turns out that in dead code, the offset can also
be negative. Guard against negative offset as well.
Fixes#30257.
Change-Id: I47c2a2e434dd466c08ae6f50f213999a358c796e
Reviewed-on: https://go-review.googlesource.com/c/162819
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit dca707b2a0)
Reviewed-on: https://go-review.googlesource.com/c/162827
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Nothing in Go can truly guarantee a key will be gone from memory (see
#21865), so remove that claim. That makes Reset useless, because
unlike most Reset methods it doesn't restore the original value state,
so deprecate it.
Change-Id: I6bb0f7f94c7e6dd4c5ac19761bc8e5df1f9ec618
Reviewed-on: https://go-review.googlesource.com/c/162297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit b35dacaac5)
Reviewed-on: https://go-review.googlesource.com/c/163438
Consider the following code:
func f(x []*T) interface{} {
return x
}
It returns an interface that holds a heap copy of x (by calling
convT2I or friend), therefore x escape to heap. The current
escape analysis only recognizes that x flows to the result. This
is not sufficient, since if the result does not escape, x's
content may be stack allocated and this will result a
heap-to-stack pointer, which is bad.
Fix this by realizing that if a CONVIFACE escapes and we're
converting from a non-direct interface type, the data needs to
escape to heap.
Running "toolstash -cmp" on std & cmd, the generated machine code
are identical for all packages. However, the export data (escape
tags) differ in the following packages. It looks to me that all
are similar to the "f" above, where the parameter should escape
to heap.
io/ioutil/ioutil.go:118
old: leaking param: r to result ~r1 level=0
new: leaking param: r
image/image.go:943
old: leaking param: p to result ~r0 level=1
new: leaking param content: p
net/url/url.go:200
old: leaking param: s to result ~r2 level=0
new: leaking param: s
(as a consequence)
net/url/url.go:183
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:194
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:699
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:775
old: (*URL).String u does not escape
new: leaking param content: u
net/url/url.go:1038
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:1099
old: (*URL).MarshalBinary u does not escape
new: leaking param content: u
flag/flag.go:235
old: leaking param: s to result ~r0 level=1
new: leaking param content: s
go/scanner/errors.go:105
old: leaking param: p to result ~r0 level=0
new: leaking param: p
database/sql/sql.go:204
old: leaking param: ns to result ~r0 level=0
new: leaking param: ns
go/constant/value.go:303
old: leaking param: re to result ~r2 level=0, leaking param: im to result ~r2 level=0
new: leaking param: re, leaking param: im
go/constant/value.go:846
old: leaking param: x to result ~r1 level=0
new: leaking param: x
encoding/xml/xml.go:518
old: leaking param: d to result ~r1 level=2
new: leaking param content: d
encoding/xml/xml.go:122
old: leaking param: leaking param: t to result ~r1 level=0
new: leaking param: t
crypto/x509/verify.go:506
old: leaking param: c to result ~r8 level=0
new: leaking param: c
crypto/x509/verify.go:563
old: leaking param: c to result ~r3 level=0, leaking param content: c
new: leaking param: c
crypto/x509/verify.go:615
old: (nothing)
new: leaking closure reference c
crypto/x509/verify.go:996
old: leaking param: c to result ~r1 level=0, leaking param content: c
new: leaking param: c
net/http/filetransport.go:30
old: leaking param: fs to result ~r1 level=0
new: leaking param: fs
net/http/h2_bundle.go:2684
old: leaking param: mh to result ~r0 level=2
new: leaking param content: mh
net/http/h2_bundle.go:7352
old: http2checkConnHeaders req does not escape
new: leaking param content: req
net/http/pprof/pprof.go:221
old: leaking param: name to result ~r1 level=0
new: leaking param: name
cmd/internal/bio/must.go:21
old: leaking param: w to result ~r1 level=0
new: leaking param: w
Fixes#29353.
Change-Id: I7e7798ae773728028b0dcae5bccb3ada51189c68
Reviewed-on: https://go-review.googlesource.com/c/162829
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 0349f29a55)
Reviewed-on: https://go-review.googlesource.com/c/163203
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In https://golang.org/cl/160998, RSA-PSS was disabled for
(most of) TLS 1.2. One place where we can't disable it is in a Client
Hello which offers both TLS 1.2 and 1.3: RSA-PSS is required by TLS 1.3,
so to offer TLS 1.3 we need to offer RSA-PSS, even if the server might
select TLS 1.2.
The good news is that we want to disable RSA-PSS mostly when we are the
signing side, as that's where broken crypto.Signer implementations will
bite us. So we can announce RSA-PSS in the Client Hello, tolerate the
server picking TLS 1.2 and RSA-PSS for their signatures, but still not
do RSA-PSS on our side if asked to provide a client certificate.
Client-TLSv12-ClientCert-RSA-PSS-Disabled changed because it was indeed
actually using RSA-PSS.
Updates #30055
Change-Id: I5ecade744b666433b37847abf55e1f08089b21d4
Reviewed-on: https://go-review.googlesource.com/c/163039
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
In runtime.gopanic, the _panic object p is stack allocated and
referenced from gp._panic. With stack objects, p on stack is dead
at the point preprintpanics runs. gp._panic points to p, but
stack scan doesn't look at gp. Heap scan of gp does look at
gp._panic, but it stops and ignores the pointer as it points to
the stack. So whatever p points to may be collected and clobbered.
We need to scan gp._panic explicitly during stack scan.
To test it reliably, we introduce a GODEBUG mode "clobberfree",
which clobbers the memory content when the GC frees an object.
Fixes#30150.
Change-Id: I11128298f03a89f817faa221421a9d332b41dced
Reviewed-on: https://go-review.googlesource.com/c/161778
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit af8f4062c2)
Reviewed-on: https://go-review.googlesource.com/c/162358
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
install.html still insisted that GOROOT must be set if a binary install
of Go is set up in a custom directory. However, since 1.10, this has
been unnecessary as the GOROOT will be found based on the location of
the 'go' binary being run.
Likewise, install-source.html includes an 'export GOROOT' line in a
section that only talks about explicitly setting GOARCH and GOOS, which
is optional. We don't want to have users think it is recommended to set
GOROOT here either, so remove the unnecessary line.
Change-Id: I7dfef09f9a1d003e0253b793d63ea40d5cf1837f
Reviewed-on: https://go-review.googlesource.com/c/161758
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When prepared on a DB, prepared statement code in database/sql handles everything to keep the prepared statement alive as it moves across the connection pool. Understanding this is an important part of using this API correctly, but it was only documented indirectly via `(*Tx) Prepare*`.
Change-Id: Ic8757e0150d59e675d9f0252f6c15aef2cc2e831
GitHub-Last-Rev: 55dba87458
GitHub-Pull-Request: golang/go#29890
Reviewed-on: https://go-review.googlesource.com/c/159077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Most of the issues that led to the decision on #30055 were related to
incompatibility with or faulty support for RSA-PSS (#29831, #29779,
v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available
to be negotiated in TLS 1.2.
Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so
just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default,
so breakage happens all at once.
Updates #30055
Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2
Reviewed-on: https://go-review.googlesource.com/c/160998
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
If a certificate somehow has an AKID, it should still chain successfully
to a parent without a SKID, even if the latter is invalid according to
RFC 5280, because only the Subject is authoritative.
This reverts to the behavior before #29233 was fixed in 770130659. Roots
with the right subject will still be shadowed by roots with the right
SKID and the wrong subject, but that's been the case for a long time, and
is left for a more complete fix in Go 1.13.
Updates #30079
Change-Id: If8ab0179aca86cb74caa926d1ef93fb5e416b4bb
Reviewed-on: https://go-review.googlesource.com/c/161097
Reviewed-by: Adam Langley <agl@golang.org>
Change-Id: Idee94a1d93555d53442098dd7479982e3f5afbba
Reviewed-on: https://go-review.googlesource.com/c/161339
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Expand modules documentation to clarify why @none is useful. The
wording is the one suggested by rsc on the issue.
Fixes#26684
Change-Id: I76dc4ff87e50f1dd8536fd9ac1fd938adb29bee3
Reviewed-on: https://go-review.googlesource.com/c/161037
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Make sure the argument to memmove is of pointer type before we try to
get the element type.
This has been noticed for code that uses unsafe+linkname so it can
call runtime.memmove. Probably not the best thing to allow, but the
code is out there and we'd rather not break it unnecessarily.
Fixes#30061
Change-Id: I334a8453f2e293959fd742044c43fbe93f0b3d31
Reviewed-on: https://go-review.googlesource.com/c/160826
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We are copying the results to uninitialized stack space. Write
barrier is not needed.
Fixes#30041.
Change-Id: Ia91d74dbafd96dc2bd92de0cb479808991dda03e
Reviewed-on: https://go-review.googlesource.com/c/160737
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
CL 159859 causes build failure with old clang versions (3.4.1) on FreeBSD 10.3/10.4.
Update #29962
Update #27619
Change-Id: I78264ac5d8d17eeae89a982e89aac988eb22b286
Reviewed-on: https://go-review.googlesource.com/c/160777
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When scavenging small amounts it's possible we over-scavenge by a
significant margin since we choose to scavenge the largest spans first.
This over-scavenging is never accounted for.
With this change, we add a scavenge credit pool, similar to the reclaim
credit pool. Any time scavenging triggered by RSS growth starts up, it
checks if it can cash in some credit first. If after using all the
credit it still needs to scavenge, then any extra it does it adds back
into the credit pool.
This change mitigates the performance impact of golang.org/cl/159500 on
the Garbage benchmark. On Go1 it suggests some improvements, but most of
that is within the realm of noise (Revcomp seems very sensitive to
GC-related changes, both postively and negatively).
Garbage: https://perf.golang.org/search?q=upload:20190131.5
Go1: https://perf.golang.org/search?q=upload:20190131.4
Performance change with both changes:
Garbage: https://perf.golang.org/search?q=upload:20190131.7
Go1: https://perf.golang.org/search?q=upload:20190131.6
Change-Id: I87bd3c183e71656fdafef94714194b9fdbb77aa2
Reviewed-on: https://go-review.googlesource.com/c/160297
Reviewed-by: Austin Clements <austin@google.com>
Because scavenged and unscavenged spans no longer coalesce, memory that
is freed no longer has a high likelihood of being re-scavenged. As a
result, if an application is allocating at a fast rate, it may work fast
enough to undo all the scavenging work performed by the runtime's
current scavenging mechanisms. This behavior is exacerbated by the
global best-fit allocation policy the runtime uses, since scavenged
spans are just as likely to be chosen as unscavenged spans on average.
To remedy that, we treat each allocation of scavenged space as a heap
growth, and scavenge other memory to make up for the allocation.
This change makes performance of the runtime slightly worse, as now
we're scavenging more often during allocation. The regression is
particularly obvious with the garbage benchmark (3%) but most of the Go1
benchmarks are within the margin of noise. A follow-up change should
help.
Garbage: https://perf.golang.org/search?q=upload:20190131.3
Go1: https://perf.golang.org/search?q=upload:20190131.2
Updates #14045.
Change-Id: I44a7e6586eca33b5f97b6d40418db53a8a7ae715
Reviewed-on: https://go-review.googlesource.com/c/159500
Reviewed-by: Austin Clements <austin@google.com>
Baokun Lee
Alberto Donizetti
Cherry Zhang
Ian Lance Taylor
fanzha02
Andrew Bonventre
Lynn Boger
Filippo Valsorda
Zhou Peng
Brad Fitzpatrick
berkant ipek
Bryan C. Mills
Daniel Martí
alkesh26
Justin Li
Yasser Abdolmaleki
Yuval Pavel Zholkover
Keith Randall
Michael Anthony Knyszek