1. 05 Jul, 2019 3 commits
  2. 03 Jul, 2019 6 commits
  3. 02 Jul, 2019 3 commits
  4. 01 Jul, 2019 2 commits
  5. 30 Jun, 2019 1 commit
    • Ian Lance Taylor's avatar
      runtime: use a pipe to wake up signal_recv on Darwin · c485e8b5
      Ian Lance Taylor authored
      The implementation of semaphores, and therefore notes, used on Darwin
      is not async-signal-safe. The runtime has one case where a note needs
      to be woken up from a signal handler: the call to notewakeup in sigsend.
      That notewakeup call is only called on a single note, and it doesn't
      need the full functionality of notes: nothing ever does a timed wait on it.
      So change that one note to use a different implementation on Darwin,
      based on a pipe. This lets the wakeup code use the write call, which is
      async-signal-safe.
      
      Fixes #31264
      
      Change-Id: If705072d7a961dd908ea9d639c8d12b222c64806
      Reviewed-on: https://go-review.googlesource.com/c/go/+/184169
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      c485e8b5
  6. 29 Jun, 2019 1 commit
    • Russ Cox's avatar
      crypto/tls: deflake localPipe in tests · 623d653d
      Russ Cox authored
      The localPipe implementation assumes that every successful net.Dial
      results in exactly one successful listener.Accept. I don't believe this
      is guaranteed by essentially any operating system. For this test, we're
      seeing flakes on dragonfly (#29583).
      
      But see also #19519, flakes due to the same assumption on FreeBSD
      and macOS in package net's own tests.
      
      This CL rewrites localPipe to try a few times to get a matching pair
      of connections on the dial and accept side.
      
      Fixes #29583.
      
      Change-Id: Idb045b18c404eae457f091df20456c5ae879a291
      Reviewed-on: https://go-review.googlesource.com/c/go/+/184157
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      623d653d
  7. 28 Jun, 2019 3 commits
    • Russ Cox's avatar
      net: deflake TestVariousDeadlines · 2e0cd2ae
      Russ Cox authored
      TestVariousDeadlines starts a client and server.
      The client dials the server, sets a timeout on the connection,
      reads from it, gets a timeout error, closes the connection.
      The server writes an infinite stream of a's to each connection
      it accepts.
      
      The test was trying to run these in lockstep:
      run a client dial+read+timeout+close,
      wait for server to accept+write+error out on write to closed connection,
      repeat.
      
      On FreeBSD 11.2 and less frequently on macOS we see
      the test timeout waiting for the server to do its half of
      the lockstep dance.
      
      I believe the problem is that the client can do its step
      of the dance with such a short timeout that the read,
      timeout, and close happens before the server ever returns
      from the accept(2) system call. For the purposes of testing
      the client-side read timeout, this is fine. But I suspect
      that under some circumstances, the "TCP-accepted"
      connection does not translate into a "socket-layer-accepted"
      connection that triggers a return from accept(2).
      That is, the Go server never sees the connection at all.
      And the test sits there waiting for it to acknowledge
      being done with a connection it never started with.
      
      Fix the problem by not trying to lockstep with the server.
      
      This definitely fixes the flake, since the specific line that
      was calling t.Fatal is now deleted.
      
      This exposes a different flake, seen on a trybot run for an
      early version of this CL, in which the client's io.Copy does
      not stop within the time allotted. The problem now is that
      there is no guarantee that a read beyond the deadline with
      available data returns an error instead of the available data,
      yet the test assumes this guarantee, and in fact the opposite
      is usually true - we don't bother checking the deadline unless
      the read needs to block. That is, deadlines don't cut off a
      flood of available data, yet this test thinks they do.
      
      This CL therefore also changes the server not to send an
      infinite flood of data - don't send any data at all - so that
      the read deadline is guaranteed to be exercised.
      
      Fixes #19519.
      
      Change-Id: I58057c3ed94ac2aebab140ea597f317abae6e65e
      Reviewed-on: https://go-review.googlesource.com/c/go/+/184137
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      2e0cd2ae
    • Russ Cox's avatar
      runtime: fix pprof cpu profile corruption on arm/mips/mipsle · 91c385b3
      Russ Cox authored
      CL 42652 changed the profile handler for mips/mipsle to
      avoid recording a profile when in atomic functions, for fear
      of interrupting the 32-bit simulation of a 64-bit atomic with
      a lock. The profile logger itself uses 64-bit atomics and might
      deadlock (#20146).
      
      The change was to accumulate a count of dropped profile events
      and then send the count when the next ordinary event was sent:
      
      	if prof.hz != 0 {
      	+	if (GOARCH == "mips" || GOARCH == "mipsle") && lostAtomic64Count > 0 {
      	+		cpuprof.addLostAtomic64(lostAtomic64Count)
      	+		lostAtomic64Count = 0
      	+	}
       		cpuprof.add(gp, stk[:n])
       	}
      
      CL 117057 extended this behavior to include GOARCH == "arm".
      
      Unfortunately, the inserted cpuprof.addLostAtomic64 differs from
      the original cpuprof.add in that it neglects to acquire the lock
      protecting the profile buffer.
      
      This has caused a steady stream of flakes on the arm builders
      for the past 12 months, ever since CL 117057 landed.
      
      This CL moves the lostAtomic count into the profile buffer and
      then lets the existing addExtra calls take care of it, instead of
      duplicating the locking logic.
      
      Fixes #24991.
      
      Change-Id: Ia386c40034fcf46b31f080ce18f2420df4bb8004
      Reviewed-on: https://go-review.googlesource.com/c/go/+/184164
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      91c385b3
    • Dmitri Shuralyov's avatar
      cmd/doc: provide working directory to build.Import calls · 3b040b7e
      Dmitri Shuralyov authored
      The current cmd/doc implementation uses go/build.Import in a few
      places to check whether a package is findable and importable.
      go/build has limited support for finding packages in modules,
      but to do so, build.Import requires knowing the source directory
      to use when performing the lookup (so it can find the go.mod file).
      Otherwise, it only looks inside the GOPATH workspace.
      
      Start passing the current working directory to build.Import calls,
      so that it can correctly look for packages in modules when in cmd/doc
      is executed in module mode.
      
      Before this change, cmd/doc in module mode could mistakenly find and
      use a package in the GOPATH workspace, instead of the current module.
      
      Since the result of os.Getwd is needed in even more places, assign it
      to a local variable in parseArgs now.
      
      Fixes #28992
      Updates #26504
      
      Change-Id: I7571618e18420d2d3b3890cc69ade2d97b1962bf
      Reviewed-on: https://go-review.googlesource.com/c/go/+/183991
      Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      3b040b7e
  8. 27 Jun, 2019 7 commits
  9. 26 Jun, 2019 14 commits