1. 08 Jan, 2016 32 commits
  2. 07 Jan, 2016 8 commits
    • Brad Fitzpatrick's avatar
      net/http: add some tests around sending & receiving star requests · 40a26c92
      Brad Fitzpatrick authored
      I thought there was still work to do in http2 for this, but I guess
      not: the work for parsing them is in net/url (used by http2) and the
      handling of OPTIONS * is already in net/http serverHandler, also used
      by http2.
      
      But keep the tests.
      
      Change-Id: I566dd0a03cf13c9ea8e735c6bd32d2c521ed503b
      Reviewed-on: https://go-review.googlesource.com/18368Reviewed-by: 's avatarBlake Mizerany <blake.mizerany@gmail.com>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      40a26c92
    • Matthew Dempsky's avatar
      cmd/compile: recognize !typedbool is typed · 27691fa4
      Matthew Dempsky authored
      Adding the evconst(n) call for OANDAND and OOROR in
      golang.org/cl/18262 was originally just to parallel the above iscmp
      branch, but upon further inspection it seemed odd that removing it
      caused test/fixedbugs/issue6671.go's
      
          var b mybool
          // ...
          b = bool(true) && true // ERROR "cannot use"
      
      to start failing (i.e., by not emitting the expected "cannot use"
      error).
      
      The problem is that evconst(n)'s settrue and setfalse paths always
      reset n.Type to idealbool, even for logical operators where n.Type
      should preserve the operand type.  Adding the evconst(n) call for
      OANDAND/OOROR inadvertantly worked around this by turning the later
      evconst(n) call at line 2167 into a noop, so the "n.Type = t"
      assignment at line 739 would preserve the operand type.
      
      However, that means evconst(n) was still clobbering n.Type for ONOT,
      so declarations like:
      
          const _ bool = !mybool(true)
      
      were erroneously accepted.
      
      Update #13821.
      
      Change-Id: I18e37287f05398fdaeecc0f0d23984e244f025da
      Reviewed-on: https://go-review.googlesource.com/18362
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      27691fa4
    • Austin Clements's avatar
      runtime: fix sigprof stack barrier locking · 3f22adec
      Austin Clements authored
      f90b48e0 intended to require the stack barrier lock in all cases of
      sigprof that walked the user stack, but got it wrong. In particular,
      if sp < gp.stack.lo || gp.stack.hi < sp, tracebackUser would be true,
      but we wouldn't acquire the stack lock. If it then turned out that we
      were in a cgo call, it would walk the stack without the lock.
      
      In fact, the whole structure of stack locking is sigprof is somewhat
      wrong because it assumes the G to lock is gp.m.curg, but all three
      gentraceback calls start from potentially different Gs.
      
      To fix this, we lower the gcTryLockStackBarriers calls much closer to
      the gentraceback calls. There are now three separate trylock calls,
      each clearly associated with a gentraceback and the locked G clearly
      matches the G from which the gentraceback starts. This actually brings
      the sigprof logic closer to what it originally was before stack
      barrier locking.
      
      This depends on "runtime: increase assumed stack size in
      externalthreadhandler" because it very slightly increases the stack
      used by sigprof; without this other commit, this is enough to blow the
      profiler thread's assumed stack size.
      
      Fixes #12528 (hopefully for real this time!).
      
      For the 1.5 branch, though it will require some backporting. On the
      1.5 branch, this will *not* require the "runtime: increase assumed
      stack size in externalthreadhandler" commit: there's no pcvalue cache,
      so the used stack is smaller.
      
      Change-Id: Id2f6446ac276848f6fc158bee550cccd03186b83
      Reviewed-on: https://go-review.googlesource.com/18328
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      3f22adec
    • Austin Clements's avatar
      runtime: increase assumed stack size in externalthreadhandler · fdf9b3c9
      Austin Clements authored
      On Windows, externalthreadhandler currently sets the assumed stack
      size for the profiler thread and the ctrlhandler threads to 8KB. The
      actual stack size is determined by the SizeOfStackReserve field in the
      binary set by the linker, which is currently at least 64KB (and
      typically 128KB).
      
      It turns out the profiler thread is running within a few words of the
      8KB-(stack guard) bound set by externalthreadhandler. If it overflows
      this bound, morestack crashes unceremoniously with an access
      violation, which we then fail to handle, causing the whole process to
      exit without explanation.
      
      To avoid this problem and give us some breathing room, increase the
      assumed stack size in externalthreadhandler to 32KB (there's some
      unknown amount of stack already in use, so it's not safe to increase
      this all the way to the reserve size).
      
      We also document the relationships between externalthreadhandler and
      SizeOfStackReserve to make this more obvious in the future.
      
      Change-Id: I2f9f9c0892076d78e09827022ff0f2bedd9680a9
      Reviewed-on: https://go-review.googlesource.com/18304
      Run-TryBot: Austin Clements <austin@google.com>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      Reviewed-by: 's avatarMinux Ma <minux@golang.org>
      fdf9b3c9
    • Austin Clements's avatar
      runtime: don't ignore success of cgo profiling tracebacks · b50b2483
      Austin Clements authored
      If a sigprof happens during a cgo call, we traceback from the entry
      point of the cgo call. However, if the SP is outside of the G's stack,
      we'll then ignore this traceback, even if it was successful, and
      overwrite it with just _ExternalCode.
      
      Fix this by accepting any successful traceback, regardless of whether
      we got it from a cgo entry point or from regular Go code.
      
      Fixes #13466.
      
      Change-Id: I5da9684361fc5964f44985d74a8cdf02ffefd213
      Reviewed-on: https://go-review.googlesource.com/18327
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      b50b2483
    • Russ Cox's avatar
      net: document ":port" syntax in Dial, Listen, ListenPacket · ebf1f0fc
      Russ Cox authored
      Change-Id: Ideb4bd9ffb1b5f1aef7d94ff791a262f54a650d5
      Reviewed-on: https://go-review.googlesource.com/18344Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      ebf1f0fc
    • Russ Cox's avatar
      runtime: add pointer to net and net/http for more GODEBUG settings · cd91c3b0
      Russ Cox authored
      net has GODEBUG text already.
      net/http still needs it (leaving for Brad).
      
      For #13611.
      
      Change-Id: Icea1027924a23a687cbbe4001985e8c6384629d7
      Reviewed-on: https://go-review.googlesource.com/18346Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      cd91c3b0
    • Brad Fitzpatrick's avatar
      net/http: update bundled http2, fixes TestConcurrentReadWriteReqBody_h2 · 305b4baf
      Brad Fitzpatrick authored
      Updates http2 to x/net git rev 520af5de654d for
      https://golang.org/cl/18370
      
      Fixes #13659
      
      Change-Id: I920eaff6036ac22c500a97449826c6b12f873d7f
      Reviewed-on: https://go-review.googlesource.com/18371
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      305b4baf