Skip to content

G
go
Switch branch/tag
  1. 09 Jan, 2020 6 commits
    • Michael Anthony Knyszek's avatar
      runtime: add scavtrace debug flag and remove scavenge info from gctrace · 8ac98e7b
      Michael Anthony Knyszek authored 
      Currently, scavenging information is printed if the gctrace debug
variable is >0. Scavenging information is also printed naively, for
every page scavenged, resulting in a lot of noise when the typical
expectation for GC trace is one line per GC.

This change adds a new GODEBUG flag called scavtrace which prints
scavenge information roughly once per GC cycle and removes any scavenge
information from gctrace. The exception is debug.FreeOSMemory, which may
force an additional line to be printed.

Fixes #32952.

Change-Id: I4177dcb85fe3f9653fd74297ea93c97c389c1811
Reviewed-on: https://go-review.googlesource.com/c/go/+/212640
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: default avatarAustin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      8ac98e7b
    • Bryan C. Mills's avatar
      cmd/go: explicitly reject 'list -u' and 'list -versions' when '-mod=vendor' is set · 509592d1
      Bryan C. Mills authored 
      The information requested by these flags is not available from the
vendor directory.

Noticed while diagnosing #36478.

Updates #33848

Change-Id: I2b181ba5c27f01fdd6277d8d0ab1003c05774ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/214081
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      509592d1
    • Bryan C. Mills's avatar
      cmd/go/internal/modload: do not disable Query for -mod=readonly · cec535b7
      Bryan C. Mills authored 
      'go list -m' allows explicit module@version arguments,
which it resolves (using Query) but does not add to the build list.
Similarly, 'go list -u' resolves versions without modifying the build list.

These explicit operations should be allowed even when '-mod=readonly' is set.

Updates #36478

'go list' and 'go mod download' do not

Change-Id: I5d2735729ad573635b9c1902d5d3a8bd960b8a76
Reviewed-on: https://go-review.googlesource.com/c/go/+/214077
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      cec535b7
    • Austin Clements's avatar
      runtime: protect against external code calling ExitProcess · 957259b7
      Austin Clements authored 
      On Windows, we implement asynchronous preemption using SuspendThread
to suspend other threads in our process. However, SuspendThread is
itself actually asynchronous (it enqueues a kernel "asynchronous
procedure call" and returns). Unfortunately, Windows' ExitProcess API
kills all threads except the calling one and then runs APCs. As a
result, if SuspendThread and ExitProcess are called simultaneously,
the exiting thread can be suspended and the suspending thread can be
exited, leaving behind a ghost process consisting of a single thread
that's suspended.

We've already protected against the runtime's own calls to
ExitProcess, but if Go code calls external code, there's nothing
stopping that code from calling ExitProcess. For example, in #35775,
our own call to racefini leads to C code calling ExitProcess and
occasionally causing a deadlock.

This CL fixes this by introducing synchronization between calling
external code on Windows and preemption. It adds an atomic field to
the M that participates in a simple CAS-based synchronization protocol
to prevent suspending a thread running external code. We use this to
protect cgocall (which is used for both cgo calls and system calls on
Windows) and racefini.

Tested by running the flag package's TestParse test compiled in race
mode in a loop. Before this change, this would reliably deadlock after
a few minutes.

Fixes #35775.
Updates #10958, #24543.

Change-Id: I50d847abcdc2688b4f71eee6a75eca0f2fee892c
Reviewed-on: https://go-review.googlesource.com/c/go/+/213837
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
      957259b7
    • Bryan C. Mills's avatar
      cmd/go: make "finding" logging deterministic · 6dbcc8b8
      Bryan C. Mills authored 
      In CL 204777, I made the "finding" messages in cachingRepo only print
after a “longish” delay, on the theory that they would help diagnose
slow or stuck fetches.

However, as I've been testing Go 1.14 beta 1, I've found that these
messages are mostly just noise, and the fact that they are so
nondeterministic causes both confusion and test flakes (#35539).

Moreover, it currently triggers once for each candidate module, when
what we're usually after is actually a specific package within the
module.

So let's log the package operation unconditionally instead of the
module fetches nondeterministically.

Fixes #35539
Updates #26152

Change-Id: I41a1c772465b2f0b357d3402bc372b6907773741
Reviewed-on: https://go-review.googlesource.com/c/go/+/213679
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      6dbcc8b8
    • Cherry Zhang's avatar
      runtime: overwrite asyncPreempt PC when injecting sigpanic on Windows · 17e97322
      Cherry Zhang authored 
      On Windows, it might be possible that SuspendThread suspends a
thread right between when an exception happens and when the
exception handler runs. (This is my guess. I don't know the
implementation detail of Windows exceptions to be sure.) In this
case, we may inject a call to asyncPreempt before the exception
handler runs. The exception handler will inject a sigpanic call,
which will make the stack trace looks like

sigpanic
asyncPreempt
actual panicking function

i.e. it appears asyncPreempt panicked.

Instead, just overwrite the PC, without pushing another frame.

Fixes #35773.

Change-Id: Ief4e964dcb7f45670b5f93c4dcf285cc1c737514
Reviewed-on: https://go-review.googlesource.com/c/go/+/213879
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      17e97322
  3. 08 Jan, 2020 4 commits
    • Bryan C. Mills's avatar
      cmd/go: adjust heuristics for skipping +incompatible versions · 817afe83
      Bryan C. Mills authored 
      We know of at least one module (github.com/stripe/stripe-go) that has
a run of +incompatible versions, followed by a run of versions with
go.mod files, followed by another run of +incompatible versions.

We want the heuristics for showing +incompatible versions to reflect
the authors' current intent, and it seems clear that the current
intent of the authors of that module is for users of the unversioned
import path to still be on +incompatible versions.

To respect that intent, we need to keep checking for +incompatible
versions even after we have seen a lower major version with an
explicit go.mod file.

However, we still don't want to download every single version of the
module to check it. A given major version should have a consistent,
canonical import path, so the path (as inferred by the presence or
absence of a go.mod file) should be the same for every release across
that major version.

To avoid unnecessary overhead — and to allow module authors to correct
accidental changes to a major version's import path — we check only
the most recent release of each major version. If a release
accidentally changes the import path in either direction (by deleting
or adding a go.mod file), it can be corrected by issuing a single
subsequent release of that major version to restore the correct path.

I manually verified that, with this change,
github.com/stripe/stripe-go@latest reverts to v68.7.0+incompatible
as it was in Go 1.13.
The other regression tests for #34165 continue to pass.

Updates #34165

Change-Id: I5daff3cd2123f94c7c49519babf4eecd509f169e
Reviewed-on: https://go-review.googlesource.com/c/go/+/212317Reviewed-by: default avatarJay Conrod <jayconrod@google.com>
      817afe83
    • Keith Randall's avatar
      cmd/compile: give every really deep type a unique name · 2248fc63
      Keith Randall authored 
      This avoids the security problem in #29312 where two very deep, but
distinct, types are given the same name. They both make it to the
linker which chooses one, and the use of the other is now type unsafe.

Instead, give every very deep type its own name. This errs on the
other side, in that very deep types that should be convertible to each
other might now not be. But at least that's not a security hole.

Update #29312.

Change-Id: Iac0ebe73fdc50594fd6fbf7432eef65f9a053126
Reviewed-on: https://go-review.googlesource.com/c/go/+/213517
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      2248fc63
    • Luka Zitnik's avatar
      net/http: document that ParseForm consumes Request.Body · 77c13021
      Luka Zitnik authored 
      Fixes #35620

Change-Id: I71bc56ec7a7507d14b4f013177b4b816bb1a2094
Reviewed-on: https://go-review.googlesource.com/c/go/+/212458Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      77c13021
    • Joel Sing's avatar
      runtime: use FP offsets for pipe/pipe2 on freebsd/arm64 and linux/arm64 · 4b1b18d1
      Joel Sing authored 
      This is more readable and less error-prone than using RSP offsets.

Suggested during review of CL 212765.

Change-Id: I070190abeeac8eae5dbd414407602619d9d57422
Reviewed-on: https://go-review.googlesource.com/c/go/+/213577
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      4b1b18d1
  5. 07 Jan, 2020 13 commits
  7. 06 Jan, 2020 17 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7