commit 96745b980cfde139e8611772e2bc0c59a8e6cdf7 [browse]
Author: Andrew Bonventre
Date: 2020-04-08 13:55:26 -04:00

[release-branch.go1.14] go1.14.2

Change-Id: I103fea634149dcbbb2bf3264e326ae86d4f67a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/227638
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>

commit bec8e9c9bdc9401b3ec95596b07ff7793cabd970 [browse]
Author: Jay Conrod
Date: 2020-02-28 16:31:19 -05:00

[release-branch.go1.14] cmd/go: make module zip extraction more robust

Currently, we extract module zip files to temporary directories, then
atomically rename them into place. On Windows, this can fail with
ERROR_ACCESS_DENIED if another process (antivirus) has files open
before the rename. In CL 220978, we repeated the rename operation in a
loop over 500 ms, but this didn't solve the problem for everyone.

A better solution will extract module zip files to their permanent
locations in the cache and will keep a ".partial" marker file,
indicating when a module hasn't been fully extracted (CL 221157).
This approach is not safe if current versions of Go access the module
cache concurrently, since the module directory is detected with a
single os.Stat.

In the interim, this CL makes two changes:

1. Flaky file system operations are repeated over 2000 ms to reduce
the chance of this error occurring.
2. cmd/go will now check for .partial files created by future
versions. If a .partial file is found, it will lock the lock file,
then remove the .partial file and directory if needed.

After some time has passed and Go versions lacking this CL are no
longer supported, we can start extracting module zip files in place.

Updates #37800

Change-Id: I467ee11aa59a90b63cf0e3e761c4fec89d57d3b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/221820
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 093049b3709eda7537ece92a2991918cf53782d6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/223147

commit 2e44aa30f0172088a36d4b2094a42866f43fc737 [browse]
Author: Jay Conrod
Date: 2020-03-18 14:59:44 -04:00

[release-branch.go1.14] cmd/go: update 'go help modules' for automatic vendoring

* Mention vendor/modules.txt verification with -mod=vendor.
* Update "Modules and vendoring" section.

Fixes #37931

Change-Id: Ia3ee72457daabaa2fc15b7ea7427eb324c088b8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/223926
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit b816cb2cd5f1b7cee660c6e4b85d8130b960752a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/224119
TryBot-Result: Gobot Gobot <gobot@golang.org>

commit c8d1e4cf833a2d36bfabda5e864a7cb357bc8b78 [browse]
Author: Austin Clements
Date: 2020-02-26 15:12:33 -05:00

[release-branch.go1.14] runtime: fix rounding in materializeGCProg

materializeGCProg allocates a temporary buffer for unrolling a GC
program. Unfortunately, when computing the size of the buffer, it
rounds *down* the number of bytes needed to store bitmap before
rounding up the number of pages needed to store those bytes. The fact
that it rounds up to pages usually mitigates the rounding down, but
the type from #37470 exists right on the boundary where this doesn't
work:

type Sequencer struct {
	htable [1 << 17]uint32
	buf    []byte
}

On 64-bit, this GC bitmap is exactly 8 KiB of zeros, followed by three
one bits. Hence, this needs 8193 bytes of storage, but the current
math in materializeGCProg rounds *down* the three one bits to 8192
bytes. Since this is exactly pageSize, the next step of rounding up to
the page size doesn't mitigate this error, and materializeGCProg
allocates a buffer that is one byte too small. runGCProg then writes
one byte past the end of this buffer, causing either a segfault (if
you're lucky!) or memory corruption.

Updates #37470.
Fixes #37480.

Change-Id: Iad24c463c501cd9b1dc1924bc2ad007991a094a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/224417
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

commit ea3a94c92e2ded0c49f77fc1ad08aa12ccabc461 [browse]
Author: Carlos Amedee
Date: 2020-01-08 14:49:43 -05:00

[release-branch.go1.14] doc: update the minimum supported macOS version to 10.11

Update minimum macOS supported version from 10.10 to 10.11.

Updates #23011

Change-Id: Ie10c40e882c9d309ff56041d9768afc288d0204f
Reviewed-on: https://go-review.googlesource.com/c/go/+/213878
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit a1bc781503bf371262d4878e96cd60cdbb5e9ee9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/226859
Run-TryBot: Carlos Amedee <carlos@golang.org>