commit a57f07aac237d366630e85d080ef1ce0c34f0d09 [browse]
Author: Andrew Bonventre
Date: 2020-04-08 13:55:51 -04:00

[release-branch.go1.13] go1.13.10

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

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

[release-branch.go1.13] 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 #37483.

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

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

[release-branch.go1.13] 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 #37802

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/+/223146

commit b79c36dc9949177aa6e2e33fe5af61d4461676a4 [browse]
Author: Carlos Eduardo Seo
Date: 2020-01-17 17:59:59 -03:00

[release-branch.go1.13] runtime: fix wrong offset when calling ppc64x nanotime syscall

There is a wrong offset when getting the results of a clock_gettime
syscall. Although the syscall will never be called in native ppc64x,
QEMU doesn't implement VDSO, so it will return wrong values.

For #36592
Fixes #38236

Change-Id: Icf838075228dcdd62cf2c1279aa983e5993d66ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/215397
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
(cherry picked from commit 71239b4f491698397149868c88d2c851de2cd49b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/227179
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

commit 9ed3fb84bc6148590757995c651bd4a6e85b4531 [browse]
Author: Dmitri Shuralyov
Date: 2020-03-17 17:50:25 -04:00

[release-branch.go1.13] cmd/go: fix and skip known Windows test failures

These non-short Windows test failures were resolved fully in CL 206144.

Both TestScript/build_trimpath and TestScript/version tests can be fixed
by backporting the changes to test scripts only, so that is done here.

Fixing TestScript/mod_list_dir requires backporting non-test changes in
addition to the test script changes, which is unlikely to be appropriate
this late in Go 1.13 release cycle. A failing test can cover up other
regressions, so skip this known failing test to fix the builder.

For #36181.

Change-Id: I4f140bd373554eb4664f04638666dee77986ec3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/223782
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>