1. 19 Aug, 2015 9 commits
  2. 18 Aug, 2015 8 commits
  3. 17 Aug, 2015 2 commits
  4. 16 Aug, 2015 1 commit
    • Dave Cheney's avatar
      cmd/compile/internal/arm64: remove Reginuse check in clearfat · 467a2cb7
      Dave Cheney authored
      Fixes golang/go#12133
      
      CL 13630 fixed the use of a stale reg[] array in the various arch
      backends which was causing the check in clearfat to pass
      unconditionally on arm64.
      
      With this check fixed, arm64 now considers REGRT1 to always be in use
      as it is part of the reserved register set, see arm64/gsubr.go.
      
      However, ppc64 does not consider REGRT1 and REGRT2 to be part of its
      reserved set, so its identical clearfat check passes.
      
      This CL removes the Reginuse check inside clearfat as REGRT1 is
      guarenteed always be free on arm64.
      
      Change-Id: I4719150d3c3378fae155b863c474529df18d4c17
      Reviewed-on: https://go-review.googlesource.com/13650Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      467a2cb7
  5. 15 Aug, 2015 3 commits
  6. 12 Aug, 2015 1 commit
  7. 11 Aug, 2015 7 commits
  8. 10 Aug, 2015 2 commits
  9. 07 Aug, 2015 4 commits
  10. 06 Aug, 2015 3 commits
    • Russ Cox's avatar
      doc: do not call WaitGroup a function · 4b145d42
      Russ Cox authored
      Fixes #12060.
      
      Change-Id: Ie2fd10bedded1a4f4e0daa0c0c77ecd898480767
      Reviewed-on: https://go-review.googlesource.com/13324Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      4b145d42
    • Austin Clements's avatar
      runtime: call goexit1 instead of goexit · ad731887
      Austin Clements authored
      Currently, runtime.Goexit() calls goexit()—the goroutine exit stub—to
      terminate the goroutine. This *mostly* works, but can cause a
      "leftover stack barriers" panic if the following happens:
      
      1. Goroutine A has a reasonably large stack.
      
      2. The garbage collector scan phase runs and installs stack barriers
         in A's stack. The top-most stack barrier happens to fall at address X.
      
      3. Goroutine A unwinds the stack far enough to be a candidate for
         stack shrinking, but not past X.
      
      4. Goroutine A calls runtime.Goexit(), which calls goexit(), which
         calls goexit1().
      
      5. The garbage collector enters mark termination.
      
      6. Goroutine A is preempted right at the prologue of goexit1() and
         performs a stack shrink, which calls gentraceback.
      
      gentraceback stops as soon as it sees goexit on the stack, which is
      only two frames up at this point, even though there may really be many
      frames above it. More to the point, the stack barrier at X is above
      the goexit frame, so gentraceback never sees that stack barrier. At
      the end of gentraceback, it checks that it saw all of the stack
      barriers and panics because it didn't see the one at X.
      
      The fix is simple: call goexit1, which actually implements the process
      of exiting a goroutine, rather than goexit, the exit stub.
      
      To make sure this doesn't happen again in the future, we also add an
      argument to the stub prototype of goexit so you really, really have to
      want to call it in order to call it. We were able to reliably
      reproduce the above sequence with a fair amount of awful code inserted
      at the right places in the runtime, but chose to change the goexit
      prototype to ensure this wouldn't happen again rather than pollute the
      runtime with ugly testing code.
      
      Change-Id: Ifb6fb53087e09a252baddadc36eebf954468f2a8
      Reviewed-on: https://go-review.googlesource.com/13323Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      ad731887
    • Russ Cox's avatar
      runtime: fix race that dropped GoSysExit events from trace · 26baed6a
      Russ Cox authored
      This makes TestTraceStressStartStop much less flaky.
      Running under stress, it changes the failure rate from
      above 1/100 to under 1/50000. That very unlikely
      failure happens when an unexpected GoSysExit is
      written. Not sure how that happens yet, but it is much
      less important.
      
      Fixes #11953.
      
      Change-Id: I034671936334b4f3ab733614ef239aa121d20247
      Reviewed-on: https://go-review.googlesource.com/13321Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      26baed6a