Skip to content

G
golang
Switch branch/tag
  1. 12 Feb, 2016 4 commits
  3. 11 Feb, 2016 1 commit
  5. 10 Feb, 2016 3 commits
  7. 09 Feb, 2016 5 commits
  9. 08 Feb, 2016 3 commits
  11. 07 Feb, 2016 1 commit
  13. 06 Feb, 2016 1 commit
    • Ian Lance Taylor's avatar
      net/http: deflake TestCloseNotifierPipelined · 54b4b946
      Ian Lance Taylor authored 
      The test sends two HTTP/1.1 pipelined requests.  The first is
completedly by the second, and as such triggers an immediate call to the
CloseNotify channel.  The second calls the CloseNotify channel after the
overall connection is closed.

The test was passing fine on gc because the code would enter the select
loop before running the handler, so the send on gotReq would always be
seen first.  On gccgo the code would sometimes enter the select loop
after the handler had already finished, meaning that the select could
choose between gotReq and sawClose.  If it picked sawClose, it would
never close the overall connection, and the httptest server would hang.
The same hang could be induced with gc by adding a time.Sleep
immediately before the select loop.

Deflake the test by 1) don't close the overall connection until both
requests have been seen; 2) don't exit the loop until both closes have
been seen.

Fixes #14231.

Change-Id: I9d20c309125422ce60ac545f78bcfa337aec1c7d
Reviewed-on: https://go-review.googlesource.com/19281Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      54b4b946
  15. 05 Feb, 2016 3 commits
  17. 04 Feb, 2016 4 commits
  19. 03 Feb, 2016 5 commits
  21. 02 Feb, 2016 8 commits
    • Russ Cox's avatar
      cmd/go: document that -msan requires clang · 22488865
      Russ Cox authored 
      Fixes #14171.

Change-Id: Ie75c1cfd88801618308d472bc04e7fc648c95e0c
Reviewed-on: https://go-review.googlesource.com/19150Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      22488865
    • Brad Fitzpatrick's avatar
      runtime/pprof: mark dragonfly and solaris as bad at pprof · beceea73
      Brad Fitzpatrick authored 
      Updates #13841

Change-Id: I121bce054e2756c820c76444e51357f474b7f3d6
Reviewed-on: https://go-review.googlesource.com/19161Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      beceea73
    • Brad Fitzpatrick's avatar
      net/http/httputil: fix spelling of Trailer hop-by-hop header per errata · 2639498f
      Brad Fitzpatrick authored 
      RFC Errata 4522 (http://www.rfc-editor.org/errata_search.php?eid=4522)
notes that RFC 2616 had a typo in a list of headers that the
httputil.ReverseProxy code copied. Fix the typo in our code.

Fixes #14174

Change-Id: Ifc8f18fd58a6508a02a23e54ff3c473f03e521d3
Reviewed-on: https://go-review.googlesource.com/19133Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      2639498f
    • Brad Fitzpatrick's avatar
      net/http: mark TestTLSServerClosesConnection as flaky on all systems · eb5bfa71
      Brad Fitzpatrick authored 
      Fixes #14195

Change-Id: I245b3ca3fd7d1a76aa95f2e058f8432ba5ce31ee
Reviewed-on: https://go-review.googlesource.com/19160
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      eb5bfa71
    • Russ Cox's avatar
      archive/zip: handle pre-zip64 zip files containing 2³²-1-byte content · b6c5edae
      Russ Cox authored 
      This corrects a regression from Go 1.5 introduced by CL 18317.

Fixes #14185.

Change-Id: Ic3215714846d9f28809cd04e3eb3664b599244f4
Reviewed-on: https://go-review.googlesource.com/19151Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      b6c5edae
    • Russ Cox's avatar
      cmd/go: avoid use of git -C, which does not exist in RHEL 7 · 8de7563a
      Russ Cox authored 
      Tested manually with "go test -run TestGetSubmodules".

Fixes #14194.

Change-Id: I4f563b2b8a38f3040d7631f74a7908ab65e0860b
Reviewed-on: https://go-review.googlesource.com/19154Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8de7563a
    • Russ Cox's avatar
      runtime: deflake TestGoroutineProfileTrivial · 1c6a35b4
      Russ Cox authored 
      Failed at https://storage.googleapis.com/go-build-log/9875de36/nacl-amd64p32_931ba6cf.log

Change-Id: I2bc204ed58da543ee2534b69c29c8e8485d54683
Reviewed-on: https://go-review.googlesource.com/19155
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      1c6a35b4
    • Austin Clements's avatar
      runtime: start an M when handing off a P when there's GC work · f309bf3e
      Austin Clements authored 
      Currently it's possible for the scheduler to deadlock with the right
confluence of locked Gs, assists, and scheduling of background mark
workers. Broadly, this happens because handoffp is stricter than
findrunnable, and if the only work for a P is GC work, handoffp will
put the P into idle, rather than starting an M to execute that P. One
way this can happen is as follows:

0. There is only one user G, which we'll call G 1. There is more than
   one P, but they're all idle except the one running G 1.

1. G 1 locks itself to an M using runtime.LockOSThread.

2. GC starts up and enters mark 1.

3. G 1 performs a GC assist, which completes mark 1 without being
   fully satisfied. Completing mark 1 causes all background mark
   workers to park. And since the assist isn't fully satisfied, it
   parks as well, waiting for a background mark worker to satisfy its
   remaining assist debt.

4. The assist park enters the scheduler. Since G 1 is locked to the M,
   the scheduler releases the P and calls handoffp to hand the P to
   another M.

5. handoffp checks the local and global run queues, which are empty,
   and sees that there are idle Ps, so rather than start an M, it puts
   the P into idle.

At this point, all of the Gs are waiting and all of the Ps are idle.
In particular, none of the GC workers are running, so no mark work
gets done and the assist on the main G is never satisfied, so the
whole process soft locks up.

Fix this by making handoffp start an M if there is GC work. This
reintroduces a key invariant: that in any situation where findrunnable
would return a G to run on a P, handoffp for that P will start an M to
run work on that P.

Fixes #13645.

Tested by running 2,689 iterations of `go tool dist test -no-rebuild
runtime:cpu124` across 10 linux-amd64-noopt VMs with no failures.
Without this change, the failure rate was somewhere around 1%.

Performance change is negligible.

name              old time/op  new time/op  delta
XBenchGarbage-12  2.48ms ± 2%  2.48ms ± 1%  -0.24%  (p=0.000 n=92+93)

name                      old time/op    new time/op    delta
BinaryTree17-12              2.86s ± 2%     2.87s ± 2%    ~     (p=0.667 n=19+20)
Fannkuch11-12                2.52s ± 1%     2.47s ± 1%  -2.05%  (p=0.000 n=18+20)
FmtFprintfEmpty-12          51.7ns ± 1%    51.5ns ± 3%    ~     (p=0.931 n=16+20)
FmtFprintfString-12          170ns ± 1%     168ns ± 1%  -0.65%  (p=0.000 n=19+19)
FmtFprintfInt-12             160ns ± 0%     160ns ± 0%  +0.18%  (p=0.033 n=17+19)
FmtFprintfIntInt-12          265ns ± 1%     273ns ± 1%  +2.98%  (p=0.000 n=17+19)
FmtFprintfPrefixedInt-12     235ns ± 1%     239ns ± 1%  +1.99%  (p=0.000 n=16+19)
FmtFprintfFloat-12           315ns ± 0%     315ns ± 1%    ~     (p=0.250 n=17+19)
FmtManyArgs-12              1.04µs ± 1%    1.05µs ± 0%  +0.87%  (p=0.000 n=17+19)
GobDecode-12                7.93ms ± 0%    7.85ms ± 1%  -1.03%  (p=0.000 n=16+18)
GobEncode-12                6.62ms ± 1%    6.58ms ± 1%  -0.60%  (p=0.000 n=18+19)
Gzip-12                      322ms ± 1%     320ms ± 1%  -0.46%  (p=0.009 n=20+20)
Gunzip-12                   42.5ms ± 1%    42.5ms ± 0%    ~     (p=0.751 n=19+19)
HTTPClientServer-12         69.7µs ± 1%    70.0µs ± 2%    ~     (p=0.056 n=19+19)
JSONEncode-12               16.9ms ± 1%    16.7ms ± 1%  -1.13%  (p=0.000 n=19+19)
JSONDecode-12               61.5ms ± 1%    61.3ms ± 1%  -0.35%  (p=0.001 n=20+17)
Mandelbrot200-12            3.94ms ± 0%    3.91ms ± 0%  -0.67%  (p=0.000 n=20+18)
GoParse-12                  3.71ms ± 1%    3.70ms ± 1%    ~     (p=0.244 n=17+19)
RegexpMatchEasy0_32-12       101ns ± 1%     102ns ± 2%  +0.54%  (p=0.037 n=19+20)
RegexpMatchEasy0_1K-12       349ns ± 0%     350ns ± 0%  +0.33%  (p=0.000 n=17+18)
RegexpMatchEasy1_32-12      84.5ns ± 2%    84.2ns ± 1%  -0.43%  (p=0.048 n=19+20)
RegexpMatchEasy1_1K-12       510ns ± 1%     513ns ± 2%  +0.58%  (p=0.002 n=18+20)
RegexpMatchMedium_32-12      132ns ± 1%     134ns ± 1%  +0.95%  (p=0.000 n=20+20)
RegexpMatchMedium_1K-12     40.1µs ± 1%    39.6µs ± 1%  -1.39%  (p=0.000 n=20+20)
RegexpMatchHard_32-12       2.08µs ± 0%    2.06µs ± 1%  -0.95%  (p=0.000 n=18+18)
RegexpMatchHard_1K-12       62.2µs ± 1%    61.9µs ± 1%  -0.42%  (p=0.001 n=19+20)
Revcomp-12                   537ms ± 0%     536ms ± 0%    ~     (p=0.076 n=20+20)
Template-12                 71.3ms ± 1%    69.3ms ± 1%  -2.75%  (p=0.000 n=20+20)
TimeParse-12                 361ns ± 0%     360ns ± 1%    ~     (p=0.056 n=19+19)
TimeFormat-12                353ns ± 0%     352ns ± 0%  -0.23%  (p=0.000 n=17+18)
[Geo mean]                  62.6µs         62.5µs       -0.17%

Change-Id: I0fbbbe4d7d99653ba5600ffb4394fa03558bc4e9
Reviewed-on: https://go-review.googlesource.com/19107Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      f309bf3e
  23. 01 Feb, 2016 2 commits