go, branch go1.14.1

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

2020-03-19T15:17:01Z

Change-Id: I3399052efb62529d32bb0866fd324d802beb6e4c Reviewed-on: https://go-review.googlesource.com/c/go/+/223923 Run-TryBot: Carlos Amedee TryBot-Result: Gobot Gobot Reviewed-by: Alexander Rakoczy

[release-branch.go1.14] doc/go1.14: mention Windows change for Open permissions

2020-03-18T20:51:21Z

For #35033 For #36878 Change-Id: Ie15353322d5cfe7320199103ad9543fb89a842ed Reviewed-on: https://go-review.googlesource.com/c/go/+/223957 Reviewed-by: Brendan Jackman Reviewed-by: Bryan C. Mills (cherry picked from commit e39de05186af24cec8a5f98258086e9899153e29) Reviewed-on: https://go-review.googlesource.com/c/go/+/223962 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.14] runtime: don't send preemption signal if there is a signal pending

2020-03-18T18:38:30Z

If multiple threads call preemptone to preempt the same M, it may send many signals to the same M such that it hardly make progress, causing live-lock problem. Only send a signal if there isn't already one pending. Updates #37741. Fixes #37833. Change-Id: Id94adb0b95acbd18b23abe637a8dcd81ab41b452 Reviewed-on: https://go-review.googlesource.com/c/go/+/223737 Run-TryBot: Cherry Zhang TryBot-Result: Gobot Gobot Reviewed-by: Keith Randall (cherry picked from commit 0c0e8f224d5724e317952f77d215a752a3a7b7d9) Reviewed-on: https://go-review.googlesource.com/c/go/+/223939 Reviewed-by: Austin Clements

[release-branch.go1.14] runtime: don't report a pointer alignment error for pointer-free base type

2020-03-18T16:19:45Z

Fixes #37905 Change-Id: I8ba9c8b106e16cea7dd25473c7390b0f2ba9a1a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/223781 Run-TryBot: Keith Randall Reviewed-by: Ian Lance Taylor Reviewed-by: Matthew Dempsky TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/c/go/+/223749

[release-branch.go1.14] runtime: don't crash on mlock failure

2020-03-16T19:55:30Z

Instead, note that mlock has failed, start trying the mitigation of touching the signal stack before sending a preemption signal, and, if the program crashes, mention the possible problem and a wiki page describing the issue (https://golang.org/wiki/LinuxKernelSignalVectorBug). Tested on a kernel in the buggy version range, but with the patch, by using `ulimit -l 0`. For #37436 Fixes #37807 Change-Id: I072aadb2101496dffd655e442fa5c367dad46ce8 Reviewed-on: https://go-review.googlesource.com/c/go/+/223121 Run-TryBot: Ian Lance Taylor Reviewed-by: Austin Clements Reviewed-by: Keith Randall (cherry picked from commit b851e51160bc8ed412e229152b430b75e7ce56f9) Reviewed-on: https://go-review.googlesource.com/c/go/+/223417 TryBot-Result: Gobot Gobot

[release-branch.go1.14] cmd/go: include the go language version in cache keys

2020-03-12T15:38:41Z

Fixes #37822 Updates #37804 Change-Id: I4381dc5c58cfd467506d3d73fbd19c2c7257338e Reviewed-on: https://go-review.googlesource.com/c/go/+/223139 Run-TryBot: Bryan C. Mills TryBot-Result: Gobot Gobot Reviewed-by: Jay Conrod (cherry picked from commit feea3f165770025b045c6dd46747b1debdaf348e) Reviewed-on: https://go-review.googlesource.com/c/go/+/223141 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.14] runtime: fix problem with repeated panic/recover/re-panics and open-coded defers

2020-03-11T14:37:29Z

In the open-code defer implementation, we add defer struct entries to the defer chain on-the-fly at panic time to represent stack frames that contain open-coded defers. This allows us to process non-open-coded and open-coded defers in the correct order. Also, we need somewhere to be able to store the 'started' state of open-coded defers. However, if a recover succeeds, defers will now be processed inline again (unless another panic happens). Any defer entry representing a frame with open-coded defers will become stale once we run the corresponding defers inline and exit the associated stack frame. So, we need to remove all entries for open-coded defers at recover time. The current code was only removing the top-most open-coded defer from the defer chain during recovery. However, with recursive functions that do repeated panic-recover-repanic, multiple stale entries can accumulate on the chain. So, we just adjust the loop to process the entire chain. Since this is at panic/recover case, it is fine to scan through the entire chain (which should usually have few elements in it, since most defers are open-coded). The added test fails with a SEGV without the fix, because it tries to run a stale open-code defer entry (and the stack has changed). Updates #37664. Fixes #37782. Change-Id: I8e3da5d610b5e607411451b66881dea887f7484d Reviewed-on: https://go-review.googlesource.com/c/go/+/222420 Run-TryBot: Dan Scales TryBot-Result: Gobot Gobot Reviewed-by: Keith Randall (cherry picked from commit fae87a2223e1fa959a20017742455200fe3c35f1) Reviewed-on: https://go-review.googlesource.com/c/go/+/222818 Run-TryBot: Dmitri Shuralyov

[release-branch.go1.14] runtime: make typehash match compiler generated hashes exactly

2020-03-10T20:06:03Z

If typehash (used by reflect) does not match the built-in map's hash, then problems occur. If a map is built using reflect, and then assigned to a variable of map type, the hash function can change. That causes very bad things. This issue is rare. MapOf consults a cache of all types that occur in the binary before making a new one. To make a true new map type (with a hash function derived from typehash) that map type must not occur in the binary anywhere. But to cause the bug, we need a variable of that type in order to assign to it. The only way to make that work is to use a named map type for the variable, so it is distinct from the unnamed version that MapOf looks for. Fixes #37721 Change-Id: I3537bfceca8cbfa1af84202f432f3c06953fe0ed Reviewed-on: https://go-review.googlesource.com/c/go/+/222357 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Cherry Zhang (cherry picked from commit 2b8e60d464515634462ca472ca09c791e2cbf6ae) Reviewed-on: https://go-review.googlesource.com/c/go/+/222778

[release-branch.go1.14] runtime: special case interface hashing for pointers

2020-03-10T20:05:44Z

Interfaces often contain pointers. Implement a fast path for this case. name old time/op new time/op delta MapInterfaceString-16 21.4ns ±19% 20.5ns ±10% ~ (p=0.361 n=10+10) MapInterfacePtr-16 25.8ns ± 8% 17.3ns ± 7% -33.11% (p=0.000 n=10+9) We need this CL as well to fix 37721. Update #37721 Fixes #37613 Change-Id: Ice52820e6259a3edeafcbbbeb25b1e363bef00d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/219338 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Cherry Zhang (cherry picked from commit afd691c579198387c874512ef1c75db651dba9bd) Reviewed-on: https://go-review.googlesource.com/c/go/+/222779 Run-TryBot: Alexander Rakoczy

[release-branch.go1.14] runtime/pprof: expand final stack frame to avoid truncation

2020-03-10T19:03:26Z

When generating stacks, the runtime automatically expands inline functions to inline all inline frames in the stack. However, due to the stack size limit, the final frame may be truncated in the middle of several inline frames at the same location. As-is, we assume that the final frame is a normal function, and emit and cache a Location for it. If we later receive a complete stack frame, we will first use the cached Location for the inlined function and then generate a new Location for the "caller" frame, in violation of the pprof requirement to merge inlined functions into the same Location. As a result, we: 1. Nondeterministically may generate a profile with the different stacks combined or split, depending on which is encountered first. This is particularly problematic when performing a diff of profiles. 2. When split stacks are generated, we lose the inlining information. We avoid both of these problems by performing a second expansion of the last stack frame to recover additional inline frames that may have been lost. This expansion is a bit simpler than the one done by the runtime because we don't have to handle skipping, and we know that the last emitted frame is not an elided wrapper, since it by definition is already included in the stack. Fixes #37447 Change-Id: If3ca2af25b21d252cf457cc867dd932f107d4c61 Reviewed-on: https://go-review.googlesource.com/c/go/+/221577 Run-TryBot: Michael Pratt TryBot-Result: Gobot Gobot Reviewed-by: Heschi Kreinick Reviewed-by: Keith Randall Reviewed-by: Hyang-Ah Hana Kim (cherry picked from commit fadbf7404d2b1aca63993e289448fcc3b6a23107) Reviewed-on: https://go-review.googlesource.com/c/go/+/222762