1. 16 Feb, 2017 3 commits
    • Chris Broadfoot's avatar
      [release-branch.go1.8] go1.8 · cd6b6202
      Chris Broadfoot authored
      Change-Id: If1e38f02db86449abd4c8a57988d9825b1cf2511
      Reviewed-on: https://go-review.googlesource.com/37132
      Run-TryBot: Chris Broadfoot <cbro@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      cd6b6202
    • Chris Broadfoot's avatar
      [release-branch.go1.8] doc: document go1.8 · 606eb9b0
      Chris Broadfoot authored
      Change-Id: Ie2144d001c6b4b2293d07b2acf62d7e3cd0b46a7
      Reviewed-on: https://go-review.googlesource.com/37130Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-on: https://go-review.googlesource.com/37131
      606eb9b0
    • Russ Cox's avatar
      [release-branch.go1.8] runtime: do not call wakep from enlistWorker, to avoid possible deadlock · bcda91c1
      Russ Cox authored
      We have seen one instance of a production job suddenly spinning to
      100% CPU and becoming unresponsive. In that one instance, a SIGQUIT
      was sent after 328 minutes of spinning, and the stacks showed a single
      goroutine in "IO wait (scan)" state.
      
      Looking for things that might get stuck if a goroutine got stuck in
      scanning a stack, we found that injectglist does:
      
      	lock(&sched.lock)
      	var n int
      	for n = 0; glist != nil; n++ {
      		gp := glist
      		glist = gp.schedlink.ptr()
      		casgstatus(gp, _Gwaiting, _Grunnable)
      		globrunqput(gp)
      	}
      	unlock(&sched.lock)
      
      and that casgstatus spins on gp.atomicstatus until the _Gscan bit goes
      away. Essentially, this code locks sched.lock and then while holding
      sched.lock, waits to lock gp.atomicstatus.
      
      The code that is doing the scan is:
      
      	if castogscanstatus(gp, s, s|_Gscan) {
      		if !gp.gcscandone {
      			scanstack(gp, gcw)
      			gp.gcscandone = true
      		}
      		restartg(gp)
      		break loop
      	}
      
      More analysis showed that scanstack can, in a rare case, end up
      calling back into code that acquires sched.lock. For example:
      
      	runtime.scanstack at proc.go:866
      	calls runtime.gentraceback at mgcmark.go:842
      	calls runtime.scanstack$1 at traceback.go:378
      	calls runtime.scanframeworker at mgcmark.go:819
      	calls runtime.scanblock at mgcmark.go:904
      	calls runtime.greyobject at mgcmark.go:1221
      	calls (*runtime.gcWork).put at mgcmark.go:1412
      	calls (*runtime.gcControllerState).enlistWorker at mgcwork.go:127
      	calls runtime.wakep at mgc.go:632
      	calls runtime.startm at proc.go:1779
      	acquires runtime.sched.lock at proc.go:1675
      
      This path was found with an automated deadlock-detecting tool.
      There are many such paths but they all go through enlistWorker -> wakep.
      
      The evidence strongly suggests that one of these paths is what caused
      the deadlock we observed. We're running those jobs with
      GOTRACEBACK=crash now to try to get more information if it happens
      again.
      
      Further refinement and analysis shows that if we drop the wakep call
      from enlistWorker, the remaining few deadlock cycles found by the tool
      are all false positives caused by not understanding the effect of calls
      to func variables.
      
      The enlistWorker -> wakep call was intended only as a performance
      optimization, it rarely executes, and if it does execute at just the
      wrong time it can (and plausibly did) cause the deadlock we saw.
      
      Comment it out, to avoid the potential deadlock.
      
      Fixes #19112.
      Unfixes #14179.
      
      Change-Id: I6f7e10b890b991c11e79fab7aeefaf70b5d5a07b
      Reviewed-on: https://go-review.googlesource.com/37093
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      Reviewed-on: https://go-review.googlesource.com/37022
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bcda91c1
  2. 15 Feb, 2017 2 commits
    • Sarah Adams's avatar
      [release-branch.go1.8] doc: update Code of Conduct wording and scope · 7d7a0a9d
      Sarah Adams authored
      This change removes the punitive language and anonymous reporting mechanism
      from the Code of Conduct document. Read on for the rationale.
      
      More than a year has passed since the Go Code of Conduct was introduced.
      In that time, there have been a small number (<30) of reports to the Working Group.
      Some reports we handled well, with positive outcomes for all involved.
      A few reports we handled badly, resulting in hurt feelings and a bad
      experience for all involved.
      
      On reflection, the reports that had positive outcomes were ones where the
      Working Group took the role of advisor/facilitator, listening to complaints and
      providing suggestions and advice to the parties involved.
      The reports that had negative outcomes were ones where the subject of the
      report felt threatened by the Working Group and Code of Conduct.
      
      After some discussion among the Working Group, we saw that we are most
      effective as facilitators, rather than disciplinarians. The various Go spaces
      already have moderators; this change to the CoC acknowledges their authority
      and places the group in a purely advisory role. If an incident is
      reported to the group we may provide information to or make a
      suggestion the moderators, but the Working Group need not (and should not) have
      any authority to take disciplinary action.
      
      In short, we want it to be clear that the Working Group are here to help
      resolve conflict, period.
      
      The second change made here is the removal of the anonymous reporting mechanism.
      To date, the quality of anonymous reports has been low, and with no way to
      reach out to the reporter for more information there is often very little we
      can do in response. Removing this one-way reporting mechanism strengthens the
      message that the Working Group are here to facilitate a constructive dialogue.
      
      Change-Id: Iee52aff5446accd0dae0c937bb3aa89709ad5fb4
      Reviewed-on: https://go-review.googlesource.com/37014Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-on: https://go-review.googlesource.com/37040Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      7d7a0a9d
    • Russ Cox's avatar
      [release-branch.go1.8] encoding/xml: fix incorrect indirect code in chardata,… · cedc511a
      Russ Cox authored
      [release-branch.go1.8] encoding/xml: fix incorrect indirect code in chardata, comment, innerxml fields
      
      The new tests in this CL have been checked against Go 1.7 as well
      and all pass in Go 1.7, with the one exception noted in a comment
      (an intentional change to omitempty already present before this CL).
      
      CL 15684 made the intentional change to omitempty.
      This CL fixes bugs introduced along the way.
      
      Most of these are corner cases that are arguably not that important,
      but they've always worked all the way back to Go 1, and someone
      cared enough to file #19063. The most significant problem found
      while adding tests is that in the case of a nil *string field with
      `xml:",chardata"`, the existing code silently stops processing not just
      that field but the entire remainder of the struct.
      Even if #19063 were not worth fixing, this chardata bug would be.
      
      Fixes #19063.
      
      Change-Id: I318cf8f9945e1a4615982d9904e109fde577ebf9
      Reviewed-on: https://go-review.googlesource.com/36954
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDaniel Martí <mvdan@mvdan.cc>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      (cherry picked from commit 72aa757d)
      Reviewed-on: https://go-review.googlesource.com/37016
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      cedc511a
  3. 13 Feb, 2017 1 commit
  4. 10 Feb, 2017 3 commits
  5. 09 Feb, 2017 1 commit
    • Daniel Theophanes's avatar
      [release-branch.go1.8] database/sql: record the context error in Rows if canceled · 3ade5406
      Daniel Theophanes authored
      Previously it was intended that Rows.Scan would return
      an error and Rows.Err would return nil. This was problematic
      because drivers could not differentiate between a normal
      Rows.Close or a context cancel close.
      
      The alternative is to require drivers to return a Scan to return
      an error if the driver is closed while there are still rows to be read.
      This is currently not how several drivers currently work and may be
      difficult to detect when there are additional rows.
      
      At the same time guard the the Rows.lasterr and prevent a close
      while a Rows operation is active.
      
      For the drivers that do not have Context methods, do not check for
      context cancelation after the operation, but before for any operation
      that may modify the database state.
      
      Fixes #18961
      
      Change-Id: I49a25318ecd9f97a35d5b50540ecd850c01cfa5e
      Reviewed-on: https://go-review.googlesource.com/36485Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-on: https://go-review.googlesource.com/36614Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      3ade5406
  6. 08 Feb, 2017 1 commit
    • Russ Cox's avatar
      [release-branch.go1.8] crypto/x509: check for new tls-ca-bundle.pem last · 0545006b
      Russ Cox authored
      We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
      to the list in response to #17549 - not being able to find any certs otherwise.
      
      Now we have #18813, where CentOS 6 apparently has both that file
      and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while
      the former is not.
      
      Moving the new CentOS 7 file to the bottom of the list should fix both
      problems: the CentOS 7 system that didn't have any of the other files
      in the list will still find the new one, and existing systems will still
      keep using what they were using instead of preferring the new path
      that may or may not be complete on some systems.
      
      Fixes #18813.
      
      Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba
      Reviewed-on: https://go-review.googlesource.com/36429
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarAdam Langley <agl@golang.org>
      Reviewed-on: https://go-review.googlesource.com/36530
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      0545006b
  7. 07 Feb, 2017 6 commits
  8. 06 Feb, 2017 3 commits
  9. 02 Feb, 2017 1 commit
  10. 01 Feb, 2017 1 commit
  11. 31 Jan, 2017 1 commit
    • Russ Cox's avatar
      [release-branch.go1.8] all: final merge of master into Go 1.8 release branch · d8d2f036
      Russ Cox authored
      After this, we will merge some of the dev work like
      type aliases and inlining into master, so any additional
      changes for the Go 1.8 release will need to be cherry-picked,
      not merged.
      
      3e55059f cmd/dist: really skip the testsanitizers tests on Android
      09496599 runtime: add explicit (void) in C to avoid GCC 7 problem
      4cffe2b6 cmd/dist: use the target GOOS to skip the test for issue 18153
      6bdb0c11 doc: update go1.8 release notes after TxOptions change
      09096bd3 cmd/go: update alldocs after CL 35150
      96ea0918 cmd/compile: use CMPWU for 32-bit or smaller unsigned Geq on ppc64{,le}
      21a8db1c doc: document go1.7.5
      
      Change-Id: I9e6a30c3fac43d4d4d15e93054ac00964c3ee958
      d8d2f036
  12. 30 Jan, 2017 2 commits
  13. 29 Jan, 2017 2 commits
  14. 28 Jan, 2017 1 commit
  15. 27 Jan, 2017 1 commit
  16. 26 Jan, 2017 6 commits
  17. 25 Jan, 2017 2 commits
  18. 24 Jan, 2017 3 commits