Comparing changes

…erSuspendResumeNotification It appears that PowerRegisterSuspendResumeNotification is not supported when running inside Docker - see issues #35447, #36557 and #37149. Our current code relies on error number to determine Docker environment. But we already saw PowerRegisterSuspendResumeNotification return ERROR_FILE_NOT_FOUND, ERROR_INVALID_PARAMETERS and ERROR_ACCESS_DENIED (see issues above). So this approach is not sustainable. Just ignore PowerRegisterSuspendResumeNotification returned error. For #37149 Fixes #37230 Change-Id: I2beba9d45cdb8c1efac5e974e747827a6261915a Reviewed-on: https://go-review.googlesource.com/c/go/+/219657 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> (cherry picked from commit d467f3b) Reviewed-on: https://go-review.googlesource.com/c/go/+/224585 Run-TryBot: Ian Lance Taylor <iant@golang.org>

…nv slice Appending to a global slice is only safe if its length is already equal to its capacity. That property is not guaranteed for slices in general, and empirically does not hold for this one. This is a minimal fix to make it easier to backport. A more robust cleanup of the base.EnvForDir function will be sent in a subsequent CL. Fixes #38082 Updates #38077 Change-Id: I731d5bbd0e516642c2cf43e713eeea15402604e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/225577 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> (cherry picked from commit bfb1342) Reviewed-on: https://go-review.googlesource.com/c/go/+/225660

…oken when present Builds upon the changes from #32000 which supported sourcing environment variables for a new process from the environment of a Windows user token when supplied. But due to the logic of os/exec, the Env field of a process was always non-nil when it reached that change. This change moves the logic up to os/exec, specifically when os.ProcAttr is being built for the os.StartProcess call, this ensures that if a user token has been supplied and no Env slice has been provided on the command it will be sourced from the user's environment. If no token is provided, or the program is compiled for any other platform than Windows, the default environment will be sourced from syscall.Environ(). For #35314 Fixes #37433 Change-Id: I4c1722e90b91945eb6980d5c5928183269b50487 GitHub-Last-Rev: 32216b7 GitHub-Pull-Request: #37402 Reviewed-on: https://go-review.googlesource.com/c/go/+/220587 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/226280

…lBeforeDo_Cancel Goroutines clean up takes longer when using deprecated CloseNotifier. For #35122. Fixes #37892. Change-Id: Id820a3012b5c781ddfb294b38ee3b009624e398c Reviewed-on: https://go-review.googlesource.com/c/go/+/204661 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 1e4a358) Reviewed-on: https://go-review.googlesource.com/c/go/+/223699 Run-TryBot: Alexander Rakoczy <alex@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>

…moveAllWithMoreErrorThanReqSize Previously we injected an error, and the injection points were (empirically) not realistic on some platforms. Instead, we now make the directory read-only, which (on most platforms) suffices to prevent the removal of its files. Also remove unused test hook, as was done in CL 204060. For #35117. For #29921. Fixes #37895. Change-Id: Ica4e2818566f8c14df3eed7c3b8de5c0abeb6963 Reviewed-on: https://go-review.googlesource.com/c/go/+/203502 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 06bdd52) Reviewed-on: https://go-review.googlesource.com/c/go/+/223700 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>

…ath separator in test Windows uses '\' not '/'. For #35175. Fixes #37901. Change-Id: Ib3d01dcf148fc0675496d5213f5bcc9cf210a6fc Reviewed-on: https://go-review.googlesource.com/c/go/+/203889 Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit a754d29) Reviewed-on: https://go-review.googlesource.com/c/go/+/223703 Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Andrew Bonventre <andybons@golang.org>

…indows This test was fixed by changing cmd/doc behavior in CL 204442. Backporting that non-test code change 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 #35236. For #36181. Change-Id: I07e795e75d7e37bc96ab68607d5d5cc9254342f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/223780 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>

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>

… 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 71239b4) 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>

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 093049b) Reviewed-on: https://go-review.googlesource.com/c/go/+/223146

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>

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>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Mar 25, 2020

Commits on Mar 26, 2020

Commits on Mar 29, 2020

Commits on Mar 31, 2020

Commits on Apr 3, 2020

Commits on Apr 7, 2020

Commits on Apr 8, 2020

This comparison is taking too long to generate.

Uh oh!