1. 19 Jan, 2016 5 commits
  2. 18 Jan, 2016 6 commits
  3. 16 Jan, 2016 3 commits
  4. 15 Jan, 2016 2 commits
    • Brad Fitzpatrick's avatar
      net/http: update bundled http2 · 91b910b7
      Brad Fitzpatrick authored
      If a user starts two HTTP requests when no http2 connection is
      available, both end up creating new TCP connections, since the
      server's protocol (h1 or h2) isn't yet known. Once it turns out that
      the server supports h2, one of the connections is useless. Previously
      we kept upgrading both TLS connections to h2 (SETTINGS frame exchange,
      etc).  Now the unnecessary connections are closed instead, before the
      h2 preface/SETTINGS.
      
      Updates x/net/http2 to git rev a8e212f3d for https://golang.org/cl/18675
      
      This CL contains the tests for https://golang.org/cl/18675
      
      Semi-related change noticed while writing the tests: now that we have
      TLSNextProto in Go 1.6, which consults the TLS
      ConnectionState.NegotiatedProtocol, we have to gurantee that the TLS
      handshake has been done before we look at the ConnectionState. So add
      that check after the DialTLS hook. (we never documented that users
      have to call Handshake, so do it for them, now that it matters)
      
      Updates #13957
      
      Change-Id: I9a70e9d1282fe937ea654d9b1269c984c4e366c0
      Reviewed-on: https://go-review.googlesource.com/18676Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      91b910b7
    • Austin Clements's avatar
      runtime: use at least "system" traceback level for runtime tests · 1556c317
      Austin Clements authored
      While the default behavior of eliding runtime frames from tracebacks
      usually makes sense, this is not the case when you're trying to test
      the runtime itself. Fix this by forcing the traceback level to at
      least "system" in the runtime tests.
      
      This will specifically help with debugging issue #13645, which has
      proven remarkably resistant to reproduction outside of the build
      dashboard itself.
      
      Change-Id: I2a8356ba6c3c5badba8bb3330fc527357ec0d296
      Reviewed-on: https://go-review.googlesource.com/18648
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      1556c317
  5. 14 Jan, 2016 15 commits
    • Matthew Dempsky's avatar
      runtime: fix darwin/arm64 build · c5a2f364
      Matthew Dempsky authored
      Fixes #13916.
      
      Change-Id: If2cad5473a749460909519ac20aca19dea8a2e7a
      Reviewed-on: https://go-review.googlesource.com/18671Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      c5a2f364
    • Russ Cox's avatar
      cmd/go: fix vendor directory check on Windows · 383d817e
      Russ Cox authored
      Fixes build.
      
      Change-Id: Idd7d87f0bf3fe553b3ab00dd32eee4925a4fe3ff
      Reviewed-on: https://go-review.googlesource.com/18647
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      383d817e
    • Ian Lance Taylor's avatar
      runtime: remove erroneous go:noescape declaration · 28f9d96c
      Ian Lance Taylor authored
      Change-Id: I6b1dc789e54a385c958961e7ba16bfd9d0f3b313
      Reviewed-on: https://go-review.googlesource.com/18629Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      28f9d96c
    • Brad Fitzpatrick's avatar
      net/http: fix flaky TestServerValidatesHostHeader · 38ca0466
      Brad Fitzpatrick authored
      Passes with go test -race -count=1000 -name=TestServerValidatesHostHeader now
      without hanging.
      
      Fixes #13950
      
      Change-Id: I41c3a555c642595c95c8c52f19a05a4c68e67630
      Reviewed-on: https://go-review.googlesource.com/18660
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      38ca0466
    • Ian Lance Taylor's avatar
      runtime: minimize time between lockextra/unlockextra · efd93a41
      Ian Lance Taylor authored
      This doesn't fix a bug, but may improve performance in programs that
      have many concurrent calls from C to Go.  The old code made several
      system calls between lockextra and unlockextra.  That could be happening
      while another thread is spinning acquiring lockextra.  This changes the
      code to not make any system calls while holding the lock.
      
      Change-Id: I50576478e478670c3d6429ad4e1b7d80f98a19d8
      Reviewed-on: https://go-review.googlesource.com/18548Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      efd93a41
    • Russ Cox's avatar
      cmd/go: respect internal directories during 'go run' · f36ee8c2
      Russ Cox authored
      Fixes #12217.
      
      Change-Id: I5ee6cb18eaa66bdec1affe689aa531c05e719fc9
      Reviewed-on: https://go-review.googlesource.com/18645Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      f36ee8c2
    • Austin Clements's avatar
      runtime: fix several issues in TestFutexsleep · 8319c578
      Austin Clements authored
      TestFutexsleep is supposed to clean up before returning by waking up
      the goroutines it started and left blocked in futex sleeps. However,
      it currently fails at this in several ways:
      
      1. Both the sleep and wakeup are done on the address of tt.mtx, but in
         both cases tt is a *local copy* of the futexsleepTest created by a
         loop, so the sleep and wakeup happen on completely different
         addresses. Fix this by making them both use the address of the
         global tt.mtx.
      
      2. If the sleep happens after the wakeup (not likely, but not
         impossible), it won't wake up. Fix this by using the futex protocol
         properly: sleep if the mutex's value is 0, and set the mutex's
         value to non-zero before doing the wakeup.
      
      3. If TestFutexsleep runs more than once, channels and mutex values
         left over from the first run will interfere with later runs. Fix
         this by clearing the mutex value and creating a new channel for
         each test and waiting for goroutines to finish before returning
         (lest they send their completion to the channel for the next run).
      
      As an added bonus, this test now actually tests that futex
      sleep/wakeup work. Previously this test would have been satisfied if
      futexsleep was an infinite loop and futexwakeup was a no-op.
      
      Change-Id: I1cbc6871cc9dcb8f4601b3621913bec2b79b0fc3
      Reviewed-on: https://go-review.googlesource.com/18617Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarMikio Hara <mikioh.mikioh@gmail.com>
      8319c578
    • Russ Cox's avatar
      cmd/go, go/build: ignore vendor directories with no Go source files · 85344291
      Russ Cox authored
      Otherwise it is impossible to vendor a/b/c without hiding the real a/b.
      I also updated golang.org/s/go15vendor.
      
      Fixes #13832.
      
      Change-Id: Iee3d53c11ea870721803f6e8e67845b405686e79
      Reviewed-on: https://go-review.googlesource.com/18644Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      85344291
    • Shenghou Ma's avatar
      build: use consistent shebang line · b73d8fbe
      Shenghou Ma authored
      Fixes #13948.
      
      Change-Id: I37d734c1241f3d72d8fe33dfdf79b573e5476b1f
      Reviewed-on: https://go-review.googlesource.com/18643Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      b73d8fbe
    • Andrew Gerrand's avatar
      doc: revise help page with categories and more links · 4a8c15e0
      Andrew Gerrand authored
      Fixes #12489
      
      Change-Id: I25dd3f76e4cfe9a71b987c3b31445724568391e9
      Reviewed-on: https://go-review.googlesource.com/18625Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      4a8c15e0
    • Russ Cox's avatar
      doc: document archive/tar changes · 353ee32f
      Russ Cox authored
      Fixes #13647.
      
      Change-Id: I28df7ade9b5abd79ce6b9c3d14ceaa988e86fc01
      Reviewed-on: https://go-review.googlesource.com/18642
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      353ee32f
    • Austin Clements's avatar
      debug/dwarf: fix nil pointer dereference in cyclic type structures · 535741a6
      Austin Clements authored
      Currently readType simultaneously constructs a type graph and resolves
      the sizes of the types. However, these two operations are
      fundamentally at odds: the order we parse a cyclic structure in may be
      different than the order we need to resolve type sizes in. As a
      result, it's possible that when readType attempts to resolve the size
      of a typedef, it may dereference a nil Type field of another typedef
      retrieved from the type cache that's only partially constructed.
      
      To fix this, we delay resolving typedef sizes until the end of the
      readType recursion, when the full type graph is constructed.
      
      Fixes #13039.
      
      Change-Id: I9889af37fb3be5437995030fdd61e45871319d07
      Reviewed-on: https://go-review.googlesource.com/18459Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      535741a6
    • Russ Cox's avatar
      cmd/compile: add AVARLIVE to peep for arm, arm64, mips64, ppc64 · 5f23bc89
      Russ Cox authored
      Fixes build on those systems.
      
      Also fix printing of AVARLIVE.
      
      Change-Id: I1b38cca0125689bc08e4e1bdd0d0c140b1ea079a
      Reviewed-on: https://go-review.googlesource.com/18641Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      5f23bc89
    • Russ Cox's avatar
      cmd/internal/obj: separate code layout from object writing · ed03dab8
      Russ Cox authored
      This will allow the compiler to crunch Prog lists down to code as each
      function is compiled, instead of waiting until the end, which should
      reduce the working set of the compiler. But not until Go 1.7.
      
      This also makes it easier to write some machine code output tests
      for the assembler, which is why it's being done now.
      
      For #13822.
      
      Change-Id: I0811123bc6e5717cebb8948f9cea18e1b9baf6f7
      Reviewed-on: https://go-review.googlesource.com/18311Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      ed03dab8
    • Russ Cox's avatar
      cmd/compile: recognize Syscall-like functions for liveness analysis · 1ac637c7
      Russ Cox authored
      Consider this code:
      
      	func f(*int)
      
      	func g() {
      		p := new(int)
      		f(p)
      	}
      
      where f is an assembly function.
      In general liveness analysis assumes that during the call to f, p is dead
      in this frame. If f has retained p, p will be found alive in f's frame and keep
      the new(int) from being garbage collected. This is all correct and works.
      We use the Go func declaration for f to give the assembly function
      liveness information (the arguments are assumed live for the entire call).
      
      Now consider this code:
      
      	func h1() {
      		p := new(int)
      		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
      	}
      
      Here syscall.Syscall is taking the place of f, but because its arguments
      are uintptr, the liveness analysis and the garbage collector ignore them.
      Since p is no longer live in h once the call starts, if the garbage collector
      scans the stack while the system call is blocked, it will find no reference
      to the new(int) and reclaim it. If the kernel is going to write to *p once
      the call finishes, reclaiming the memory is a mistake.
      
      We can't change the arguments or the liveness information for
      syscall.Syscall itself, both for compatibility and because sometimes the
      arguments really are integers, and the garbage collector will get quite upset
      if it finds an integer where it expects a pointer. The problem is that
      these arguments are fundamentally untyped.
      
      The solution we have taken in the syscall package's wrappers in past
      releases is to insert a call to a dummy function named "use", to make
      it look like the argument is live during the call to syscall.Syscall:
      
      	func h2() {
      		p := new(int)
      		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
      		use(unsafe.Pointer(p))
      	}
      
      Keeping p alive during the call means that if the garbage collector
      scans the stack during the system call now, it will find the reference to p.
      
      Unfortunately, this approach is not available to users outside syscall,
      because 'use' is unexported, and people also have to realize they need
      to use it and do so. There is much existing code using syscall.Syscall
      without a 'use'-like function. That code will fail very occasionally in
      mysterious ways (see #13372).
      
      This CL fixes all that existing code by making the compiler do the right
      thing automatically, without any code modifications. That is, it takes h1
      above, which is incorrect code today, and makes it correct code.
      
      Specifically, if the compiler sees a foreign func definition (one
      without a body) that has uintptr arguments, it marks those arguments
      as "unsafe uintptrs". If it later sees the function being called
      with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
      as having escaped, and it makes sure to hold x in a live temporary
      variable until the call returns, so that the garbage collector cannot
      reclaim whatever heap memory x points to.
      
      For now I am leaving the explicit calls to use in package syscall,
      but they can be removed early in a future cycle (likely Go 1.7).
      
      The rule has no effect on escape analysis, only on liveness analysis.
      
      Fixes #13372.
      
      Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
      Reviewed-on: https://go-review.googlesource.com/18584Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      1ac637c7
  6. 13 Jan, 2016 9 commits