commit 3d344611770d03a9d2f822216074edd83af67677 [browse]
Author: Andrew Gerrand
Date: 2014-12-02 13:43:43 +11:00

go1.4rc2

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/179700043

commit 28208eb8e3e887a5490e5adbbbe39c2da4278262 [browse]
Author: Russ Cox
Date: 2014-12-01 16:42:41 -05:00

[release-branch.go1.4] runtime: fix hang in GC due to shrinkstack vs netpoll race

««« CL 179680043 / 752cd9199639
runtime: fix hang in GC due to shrinkstack vs netpoll race

During garbage collection, after scanning a stack, we think about
shrinking it to reclaim some memory. The shrinking code (called
while the world is stopped) checked that the status was Gwaiting
or Grunnable and then changed the state to Gcopystack, to essentially
lock the stack so that no other GC thread is scanning it.
The same locking happens for stack growth (and is more necessary there).

        oldstatus = runtime·readgstatus(gp);
        oldstatus &= ~Gscan;
        if(oldstatus == Gwaiting || oldstatus == Grunnable)
                runtime·casgstatus(gp, oldstatus, Gcopystack); // oldstatus is Gwaiting or Grunnable
        else
                runtime·throw("copystack: bad status, not Gwaiting or Grunnable");

Unfortunately, "stop the world" doesn't stop everything. It stops all
normal goroutine execution, but the network polling thread is still
blocked in epoll and may wake up. If it does, and it chooses a goroutine
to mark runnable, and that goroutine is the one whose stack is shrinking,
then it can happen that between readgstatus and casgstatus, the status
changes from Gwaiting to Grunnable.

casgstatus assumes that if the status is not what is expected, it is a
transient change (like from Gwaiting to Gscanwaiting and back, or like
from Gwaiting to Gcopystack and back), and it loops until the status
has been restored to the expected value. In this case, the status has
changed semi-permanently from Gwaiting to Grunnable - it won't
change again until the GC is done and the world can continue, but the
GC is waiting for the status to change back. This wedges the program.

To fix, call a special variant of casgstatus that accepts either Gwaiting
or Grunnable as valid statuses.

Without the fix bug with the extra check+throw in casgstatus, the
program below dies in a few seconds (2-10) with GOMAXPROCS=8
on a 2012 Retina MacBook Pro. With the fix, it runs for minutes
and minutes.

package main

import (
        "io"
        "log"
        "net"
        "runtime"
)

func main() {
        const N = 100
        for i := 0; i < N; i++ {
                l, err := net.Listen("tcp", "127.0.0.1:0")
                if err != nil {
                        log.Fatal(err)
                }
                ch := make(chan net.Conn, 1)
                go func() {
                        var err error
                        c1, err := net.Dial("tcp", l.Addr().String())
                        if err != nil {
                                log.Fatal(err)
                        }
                        ch <- c1
                }()
                c2, err := l.Accept()
                if err != nil {
                        log.Fatal(err)
                }
                c1 := <-ch
                l.Close()
                go netguy(c1, c2)
                go netguy(c2, c1)
                c1.Write(make([]byte, 100))
        }
        for {
                runtime.GC()
        }
}

func netguy(r, w net.Conn) {
        buf := make([]byte, 100)
        for {
                bigstack(1000)
                _, err := io.ReadFull(r, buf)
                if err != nil {
                        log.Fatal(err)
                }
                w.Write(buf)
        }
}

var g int

func bigstack(n int) {
        var buf [100]byte
        if n > 0 {
                bigstack(n - 1)
        }
        g = int(buf[0]) + int(buf[99])
}

Fixes #9186.

LGTM=rlh
R=austin, rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/179680043
»»»

TBR=rlh
CC=golang-codereviews
https://golang.org/cl/184030043

commit 95e92ac420ca0edaa9dabdbe76583affbc1015a0 [browse]
Author: Russ Cox
Date: 2014-12-01 11:18:47 -05:00

[release-branch.go1.4] reflect: Fix reflect.funcLayout.  The GC bitmap has two bits per

««« CL 182160043 / 321d04dea9d6
reflect: Fix reflect.funcLayout.  The GC bitmap has two bits per
pointer, not one.

Fixes #9179

LGTM=iant, rsc
R=golang-codereviews, iant, rsc
CC=golang-codereviews
https://golang.org/cl/182160043
»»»

TBR=khr
CC=golang-codereviews
https://golang.org/cl/180440044

commit 783ad67982a79221df36f70c6986344fef83f9b5 [browse]
Author: Andrew Gerrand
Date: 2014-11-26 07:57:03 +11:00

[release-branch.go1.4] doc: tidy up "Projects" page; add Go 1.4

««« CL 182750043 / ffe33f1f1f17
doc: tidy up "Projects" page; add Go 1.4

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/182750043
»»»

TBR=r
CC=golang-codereviews
https://golang.org/cl/176350043

commit d3ae115c4147bc18ada612ce63760eae8d1be359 [browse]
Author: Russ Cox
Date: 2014-11-24 22:00:01 -05:00

[release-branch.go1.4] go/build: build $GOOS_test.go always

««« CL 176290043 / 8025b7d1e6c9
go/build: build $GOOS_test.go always

We decided to build $GOOS.go always
but forgot to test $GOOS_test.go.

Fixes #9159.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/176290043
»»»

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/182740043