1. 09 Feb, 2016 2 commits
  2. 08 Feb, 2016 3 commits
  3. 07 Feb, 2016 1 commit
  4. 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
  5. 05 Feb, 2016 3 commits
  6. 04 Feb, 2016 4 commits
  7. 03 Feb, 2016 5 commits
  8. 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
  9. 01 Feb, 2016 3 commits
  10. 29 Jan, 2016 6 commits
  11. 28 Jan, 2016 2 commits
  12. 27 Jan, 2016 2 commits