go, branch go1.14.10

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

2020-10-14T19:10:36Z

Change-Id: Ia983336cdedc9fa835bfc792dd1e819eef31596f Reviewed-on: https://go-review.googlesource.com/c/go/+/262338 Run-TryBot: Alexander Rakoczy Reviewed-by: Dmitri Shuralyov TryBot-Result: Go Bot Trust: Alexander Rakoczy

[release-branch.go1.14] runtime: correct signature of call16

2020-10-14T15:11:38Z

The signature of call16 is currently missing the "typ" parameter. This CL fixes this. This wasn't caught by vet because call16 is defined by macro expansion (see #17544), and we didn't notice the mismatch with the other call* functions because call16 is defined only on 32-bit architectures and lives alone in stubs32.go. Unfortunately, this means its GC signature is also wrong: the "arg" parameter is treated as a scalar rather than a pointer, so GC won't trace it and stack copying won't adjust it. This turns out to matter in exactly one case right now: on 32-bit architectures (which are the only architectures where call16 is defined), a stack-allocated defer of a function with a 16-byte or smaller argument frame including a non-empty result area can corrupt memory if the deferred function grows the stack and is invoked during a panic. Whew. All other current uses of reflectcall pass a heap-allocated "arg" frame (which happens to be reachable from other stack roots, so tracing isn't a problem). Curiously, in 2016, the signatures of all call* functions were wrong in exactly this way. CL 31654 fixed all of them in stubs.go, but missed the one in stubs32.go. Updates #41795. Fixes #41796. Change-Id: I31e3c0df201f79ee5707eeb8dc4ff0d13fc10ada Reviewed-on: https://go-review.googlesource.com/c/go/+/259338 Trust: Austin Clements Run-TryBot: Austin Clements TryBot-Result: Go Bot Reviewed-by: Cherry Zhang Reviewed-on: https://go-review.googlesource.com/c/go/+/259597

[release-branch.go1.14] database/sql: de-flake TestTxCannotCommitAfterRollback

2020-10-08T21:03:57Z

Do not cancel rows during test. Only cancel the Tx. Correct the referenced issue number on the test. Updates #38597. Fixes #41815. Change-Id: I0e8ba1bf2a8ba638d121c9c6938501fec1d5e961 Reviewed-on: https://go-review.googlesource.com/c/go/+/229478 Run-TryBot: Daniel Theophanes TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor (cherry picked from commit ed7888aea6021e25b0ea58bcad3f26da2b139432) Reviewed-on: https://go-review.googlesource.com/c/go/+/259858 Trust: Dmitri Shuralyov Trust: Emmanuel Odeke Run-TryBot: Dmitri Shuralyov Reviewed-by: Emmanuel Odeke TryBot-Result: Go Bot

[release-branch.go1.14] runtime: disable stack shrinking in activeStackChans race window

2020-10-07T20:34:20Z

Currently activeStackChans is set before a goroutine blocks on a channel operation in an unlockf passed to gopark. The trouble is that the unlockf is called *after* the G's status is changed, and the G's status is what is used by a concurrent mark worker (calling suspendG) to determine that a G has successfully been suspended. In this window between the status change and unlockf, the mark worker could try to shrink the G's stack, and in particular observe that activeStackChans is false. This observation will cause the mark worker to *not* synchronize with concurrent channel operations when it should, and so updating pointers in the sudog for the blocked goroutine (which may point to the goroutine's stack) races with channel operations which may also manipulate the pointer (read it, dereference it, update it, etc.). Fix the problem by adding a new atomically-updated flag to the g struct called parkingOnChan, which is non-zero in the race window above. Then, in isShrinkStackSafe, check if parkingOnChan is zero. The race is resolved like so: * Blocking G sets parkingOnChan, then changes status in gopark. * Mark worker successfully suspends blocking G. * If the mark worker observes parkingOnChan is non-zero when checking isShrinkStackSafe, then it's not safe to shrink (we're in the race window). * If the mark worker observes parkingOnChan as zero, then because the mark worker observed the G status change, it can be sure that gopark's unlockf completed, and gp.activeStackChans will be correct. The risk of this change is low, since although it reduces the number of places that stack shrinking is allowed, the window here is incredibly small. Essentially, every place that it might crash now is replaced with no shrink. This change adds a test, but the race window is so small that it's hard to trigger without a well-placed sleep in park_m. Also, this change fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte stack frame. It turns out the compiler was destructuring the "pad" field and only allocating one uint64 on the stack. For #40641. Fixes #40642. Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/247050 Run-TryBot: Michael Knyszek TryBot-Result: Go Bot Reviewed-by: Michael Pratt Trust: Michael Knyszek (cherry picked from commit eb3c6a93c3236bbde5dee6cc5bd4ca9f8ab1647a) Reviewed-on: https://go-review.googlesource.com/c/go/+/256301 Reviewed-by: Austin Clements

[release-branch.go1.14] cmd/compile: fix live variable computation for deferreturn

2020-10-05T23:02:02Z

Taking the live variable set from the last return point is problematic. See #40629 for details, but there may not be a return point, or it may be before the final defer. Additionally, keeping track of the last call as a *Value doesn't quite work. If it is dead-code eliminated, the storage for the Value is reused for some other random instruction. Its live variable information, if it is available at all, is wrong. Instead, just mark all the open-defer argument slots as live throughout the function. (They are already zero-initialized.) Fixes #40647 Change-Id: Ie456c7db3082d0de57eaa5234a0f32525a1cce13 Reviewed-on: https://go-review.googlesource.com/c/go/+/247522 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Dan Scales (cherry picked from commit 32a84c99e136ed5af0686dbedd31fd7dff40fb38) Reviewed-on: https://go-review.googlesource.com/c/go/+/248622 TryBot-Result: Go Bot Trust: Dmitri Shuralyov

[release-branch.go1.14] testing: flush test summaries to stdout atomically when streaming output

2020-10-05T22:50:05Z

While debugging #40771, I realized that the chatty printer should only ever print to a single io.Writer (normally os.Stdout). The other Writer implementations in the chain write to local buffers, but if we wrote a test's output to a local buffer, then we did *not* write it to stdout and we should not store it as the most recently logged test. Because the chatty printer should only ever print to one place, it shouldn't receive an io.Writer as an argument — rather, it shouldn't be used at all for destinations other than the main output stream. On the other hand, when we flush the output buffer to stdout in the top-level flushToParent call, it is important that we not allow some other test's output to intrude between the test summary header and the remainder of the test's output. cmd/test2json doesn't know how to parse such an intrusion, and it's confusing to humans too. No test because I couldn't reproduce the user-reported error without modifying the testing package. (This behavior seems to be very sensitive to output size and/or goroutine scheduling.) Fixes #40880 Updates #40771 Updates #38458 Change-Id: Ic19bf1d535672b096ba1c8583a3b74aab6d6d766 Reviewed-on: https://go-review.googlesource.com/c/go/+/249026 Run-TryBot: Bryan C. Mills TryBot-Result: Gobot Gobot Reviewed-by: Jay Conrod Reviewed-by: Ian Lance Taylor (cherry picked from commit 51c0bdc6d15dcd7f753c25896039ab41ac787ebb) Reviewed-on: https://go-review.googlesource.com/c/go/+/252638 TryBot-Result: Go Bot Trust: Bryan C. Mills

[release-branch.go1.14] cmd/compile: prevent 387+float32+pie from clobbering registers

2020-10-01T18:28:45Z

The 387 port needs to load a floating-point control word from a global location to implement float32 arithmetic. When compiling with -pie, loading that control word clobbers an integer register. If that register had something important in it, boom. Fix by using LEAL to materialize the address of the global location first. LEAL with -pie works because the destination register is used as the scratch register. 387 support is about to go away (#40255), so this will need to be backported to have any effect. No test. I have one, but it requires building with -pie, which requires cgo. Our testing infrastructure doesn't make that easy. Not worth it for a port which is about to vanish. Fixes #41619 Change-Id: I140f9fc8fdce4e74a52c2c046e2bd30ae476d295 Reviewed-on: https://go-review.googlesource.com/c/go/+/257277 Run-TryBot: Keith Randall Reviewed-by: Cherry Zhang Reviewed-by: Matthew Dempsky TryBot-Result: Go Bot Trust: Keith Randall (cherry picked from commit ea106cc07ac73110a8a25fcc5aef07b283159db0) Reviewed-on: https://go-review.googlesource.com/c/go/+/257208

[release-branch.go1.14] runtime: fix ReadMemStatsSlow's and CheckScavengedBits' chunk iteration

2020-09-10T18:38:25Z

Both ReadMemStatsSlow and CheckScavengedBits iterate over the page allocator's chunks but don't actually check if they exist. During the development process the chunks index became sparse, so now this was a possibility. If the runtime tests' heap is sparse we might end up segfaulting in either one of these functions, though this will generally be very rare. The pattern here to return nil for a nonexistent chunk is also useful elsewhere, so this change introduces tryChunkOf which won't throw, but might return nil. It also updates the documentation of chunkOf. For #41296. Fixes #41322. Change-Id: Id5ae0ca3234480de1724fdf2e3677eeedcf76fa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/253777 Run-TryBot: Michael Knyszek Reviewed-by: Keith Randall TryBot-Result: Gobot Gobot (cherry picked from commit 34835df04891a1d54394888b763af88f9476101d) Reviewed-on: https://go-review.googlesource.com/c/go/+/253922 Run-TryBot: Dmitri Shuralyov Reviewed-by: Michael Knyszek

[release-branch.go1.14] cmd/internal/obj: fix inline marker issue on s390x

2020-09-10T18:30:06Z

The optimization that replaces inline markers with pre-existing instructions assumes that 'Prog' values produced by the compiler are still reachable after the assembler has run. This was not true on s390x where the assembler was removing NOP instructions from the linked list of 'Prog' values. This led to broken inlining data which in turn caused an infinite loop in the runtime traceback code. Fix this by stopping the s390x assembler backend removing NOP values. It does not make any difference to the output of the assembler because NOP instructions are 0 bytes long anyway. Note: compiler check omitted from backport to reduce risk of change. Fixes #40694. Change-Id: I9f9bdbe895c3478549b5e7e623f9521f841e926a Reviewed-on: https://go-review.googlesource.com/c/go/+/248477 Run-TryBot: Michael Munday TryBot-Result: Gobot Gobot Reviewed-by: Dmitri Shuralyov Reviewed-by: Keith Randall

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

2020-09-09T16:38:16Z

Change-Id: I556ecd19f81692ddbd3faf1d918e36466833f12e Reviewed-on: https://go-review.googlesource.com/c/go/+/253737 Run-TryBot: Dmitri Shuralyov Reviewed-by: Alexander Rakoczy TryBot-Result: Gobot Gobot