go, branch go1.13.12

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

2020-06-01T19:34:58Z

Change-Id: I1989d7cab0bf75c4e42d1c48146be9131d2c105c Reviewed-on: https://go-review.googlesource.com/c/go/+/235918 Run-TryBot: Dmitri Shuralyov TryBot-Result: Gobot Gobot Reviewed-by: Andrew Bonventre

[release-branch.go1.13] math/big: make Rat.Denom side-effect free

2020-05-27T22:53:26Z

A Rat is represented via a quotient a/b where a and b are Int values. To make it possible to use an uninitialized Rat value (with a and b uninitialized and thus == 0), the implementation treats a 0 denominator as 1. Rat.Num and Rat.Denom return pointers to these values a and b. Because b may be 0, Rat.Denom used to first initialize it to 1 and thus produce an undesirable side-effect (by changing the Rat's denominator). This CL changes Denom to return a new (not shared) *Int with value 1 in the rare case where the Rat was not initialized. This eliminates the side effect and returns the correct denominator value. While this is changing behavior of the API, the impact should now be minor because together with (prior) CL https://golang.org/cl/202997, which initializes Rats ASAP, Denom is unlikely used to access the denominator of an uninitialized (and thus 0) Rat. Any operation that will somehow set a Rat value will ensure that the denominator is not 0. Fixes #36689. For #33792. For #3521. Change-Id: I0bf15ac60513cf52162bfb62440817ba36f0c3fc Reviewed-on: https://go-review.googlesource.com/c/go/+/203059 Run-TryBot: Robert Griesemer TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick Reviewed-on: https://go-review.googlesource.com/c/go/+/233323 Reviewed-by: Emmanuel Odeke Run-TryBot: Dmitri Shuralyov

[release-branch.go1.13] math/big: normalize unitialized denominators ASAP

2020-05-27T22:52:28Z

A Rat is represented via a quotient a/b where a and b are Int values. To make it possible to use an uninitialized Rat value (with a and b uninitialized and thus == 0), the implementation treats a 0 denominator as 1. For each operation we check if the denominator is 0, and then treat it as 1 (if necessary). Operations that create a new Rat result, normalize that value such that a result denominator 1 is represened as 0 again. This CL changes this behavior slightly: 0 denominators are still interpreted as 1, but whenever we (safely) can, we set an uninitialized 0 denominator to 1. This simplifies the code overall. Also: Improved some doc strings. Preparation for addressing issue #33792. For #36689. For #33792. Change-Id: I3040587c8d0dad2e840022f96ca027d8470878a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/202997 Run-TryBot: Robert Griesemer TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick Reviewed-on: https://go-review.googlesource.com/c/go/+/233322 Run-TryBot: Dmitri Shuralyov Reviewed-by: Emmanuel Odeke

[release-branch.go1.13] math/big: make Rat accessors safe for concurrent use

2020-05-27T22:52:06Z

Do not modify the underlying Rat denominator when calling one of the accessors Float32, Float64; verify that we don't modify the Rat denominator when calling Inv, Sign, IsInt, Num. For #36689. For #34919. For #33792. Change-Id: Ife6d1252373f493a597398ee51e7b5695b708df5 Reviewed-on: https://go-review.googlesource.com/c/go/+/201205 Reviewed-by: Ian Lance Taylor Reviewed-on: https://go-review.googlesource.com/c/go/+/233321 Run-TryBot: Dmitri Shuralyov TryBot-Result: Gobot Gobot Reviewed-by: Emmanuel Odeke

[release-branch.go1.13] runtime: disable preemption in startTemplateThread

2020-05-27T17:55:05Z

When a locked M wants to start a new M, it hands off to the template thread to actually call clone and start the thread. The template thread is lazily created the first time a thread is locked (or if cgo is in use). stoplockedm will release the P (_Pidle), then call handoffp to give the P to another M. In the case of a pending STW, one of two things can happen: 1. handoffp starts an M, which does acquirep followed by schedule, which will finally enter _Pgcstop. 2. handoffp immediately enters _Pgcstop. This only occurs if the P has no local work, GC work, and no spinning M is required. If handoffp starts an M, and must create a new M to do so, then newm will simply queue the M on newmHandoff for the template thread to do the clone. When a stop-the-world is required, stopTheWorldWithSema will start the stop and then wait for all Ps to enter _Pgcstop. If the template thread is not fully created because startTemplateThread gets stopped, then another stoplockedm may queue an M that will never get created, and the handoff P will never leave _Pidle. Thus stopTheWorldWithSema will wait forever. A sequence to trigger this hang when STW occurs can be visualized with two threads: T1 T2 ------------------------------- ----------------------------- LockOSThread LockOSThread haveTemplateThread == 0 startTemplateThread haveTemplateThread = 1 newm haveTemplateThread == 1 preempt -> schedule g.m.lockedExt++ gcstopm -> _Pgcstop g.m.lockedg = ... park g.lockedm = ... return ... (any code) preempt -> schedule stoplockedm releasep -> _Pidle handoffp startm (first 3 handoffp cases) newm g.m.lockedExt != 0 Add to newmHandoff, return park Note that the P in T2 is stuck sitting in _Pidle. Since the template thread isn't running, the new M will not be started complete the transition to _Pgcstop. To resolve this, we disable preemption around the assignment of haveTemplateThread and the creation of the template thread in order to guarantee that if handTemplateThread is set then the template thread will eventually exist, in the presence of stops. For #38931 Fixes #38932 Change-Id: I50535fbbe2f328f47b18e24d9030136719274191 Reviewed-on: https://go-review.googlesource.com/c/go/+/232978 Run-TryBot: Michael Pratt Reviewed-by: Austin Clements TryBot-Result: Gobot Gobot (cherry picked from commit 11b3730a02c93fd5745bfd977156541a9033759b) Reviewed-on: https://go-review.googlesource.com/c/go/+/234888 Reviewed-by: Cherry Zhang

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

2020-05-14T19:18:42Z

Change-Id: I6fb5fbb3caf64e7d33412be4893edf8564e3a4de Reviewed-on: https://go-review.googlesource.com/c/go/+/234001 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13] cmd/compile: fix deallocation of live value copies in regalloc

2020-04-28T16:29:29Z

When deallocating the input register to a phi so that the phi itself could be allocated to that register the code was also deallocating all copies of that phi input value. Those copies of the value could still be live and if they were the register allocator could reuse them incorrectly to hold speculative copies of other phi inputs. This causes strange bugs. No test because this is a very obscure scenario that is hard to replicate but CL 228060 adds an assertion to the compiler that does trigger when running the std tests on linux/s390x without this CL applied. Hopefully that assertion will prevent future regressions. Fixes #38442. Change-Id: Id975dadedd731c7bb21933b9ea6b17daaa5c9e1d Reviewed-on: https://go-review.googlesource.com/c/go/+/228061 Run-TryBot: Michael Munday TryBot-Result: Gobot Gobot Reviewed-by: Keith Randall (cherry picked from commit 382fe3e2498f2066400e7e7007aa9903440e339d) Reviewed-on: https://go-review.googlesource.com/c/go/+/230358

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

2020-04-08T19:09:06Z

Change-Id: I1ed1bc6652724d2e365f89de802c79ecc5c2660d Reviewed-on: https://go-review.googlesource.com/c/go/+/227639 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Alexander Rakoczy

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

2020-04-07T20:06:38Z

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 Reviewed-by: Cherry Zhang TryBot-Result: Gobot Gobot

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

2020-04-07T20:06:16Z

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 TryBot-Result: Gobot Gobot Reviewed-by: Michael Matloob Reviewed-by: Bryan C. Mills (cherry picked from commit 093049b3709eda7537ece92a2991918cf53782d6) Reviewed-on: https://go-review.googlesource.com/c/go/+/223146