Skip to content

G
go
Switch branch/tag
  1. 02 Dec, 2016 3 commits
  3. 01 Dec, 2016 31 commits
  5. 30 Nov, 2016 6 commits
    • Russ Cox's avatar
      cmd/go: document GOPATH default exception · 5dd4d6ed
      Russ Cox authored 
      Doesn't get defaulted if $HOME/go is a GOROOT.

Change-Id: I6ac8211a74029e4ad70a50f6e7884a039a27ab05
Reviewed-on: https://go-review.googlesource.com/33720
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5dd4d6ed
    • Russ Cox's avatar
      doc, cmd/go: adjust documentation for default GOPATH · 74628a8b
      Russ Cox authored 
      Replaces CL 33356.

Fixes #17262.

Change-Id: Idfb2343e90771775e51a66c63760f458737a288c
Reviewed-on: https://go-review.googlesource.com/33730
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      74628a8b
    • David Lazar's avatar
      cmd/compile: generate code that type checks when inlining variadic functions · 5d1b53a9
      David Lazar authored 
      This fixes a bug in -l=3 or higher.

To inline a variadic function, the compiler generates code that constructs
a slice of arguments for the variadic parameter. Consider the function

  func Foo(xs ...string)

and the call Foo("hello", "world"). To inline the call to Foo, the
compiler used to generate

  xs := [2]string{"hello", "world"}[:]

which doesn't type check:

  invalid operation [2]string literal[:] (slice of unaddressable value).

Now, the compiler generates

  xs := []string{"hello", "world"}

which does type check.

Fixes #18116.

Change-Id: I0ee531ef2e6cc276db6fb12602b25a46d6d5db21
Reviewed-on: https://go-review.googlesource.com/33671Reviewed-by: default avatarKeith Randall <khr@golang.org>
      5d1b53a9
    • Brad Fitzpatrick's avatar
      doc: document default GOPATH in go1.8.html · 01dda422
      Brad Fitzpatrick authored 
      And fix a bad link.

TBR=See https://golang.org/cl/33244

Updates #17929

Change-Id: Ib16cf55cdc4a5340f2f4f96ad5934a9fe7d49d75
Reviewed-on: https://go-review.googlesource.com/33716Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      01dda422
    • Daniel Theophanes's avatar
      database/sql: deflake query cancel tests · 2a64ebfc
      Daniel Theophanes authored 
      Rather then using a sleep in the fake DB, go to a channel
select and wait for the context to be done.

Fixes #18115

Change-Id: I6bc3a29db58c568d0a7ea06c2a354c18c9e798b2
Reviewed-on: https://go-review.googlesource.com/33712
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      2a64ebfc
    • Austin Clements's avatar
      runtime: fix undead arguments in cgocall · f6bff1d5
      Austin Clements authored 
      From the garbage collector's perspective, time can move backwards in
cgocall. However, in the midst of this time warp, the pointer
arguments to cgocall can go from dead back to live. If a stack growth
happens while they're dead and then a GC happens when they become live
again, GC can crash with a bad heap pointer.

Specifically, the sequence that leads to a panic is:

1. cgocall calls entersyscall, which saves the PC and SP of its call
site in cgocall. Call this PC/SP "X". At "X" both pointer arguments
are live.

2. cgocall calls asmcgocall. Call the PC/SP of this call "Y". At "Y"
neither pointer argument is live.

3. asmcgocall calls the C code, which eventually calls back into the
Go code.

4. cgocallbackg remembers the saved PC/SP "X" in some local variables,
calls exitsyscall, and then calls cgocallbackg1.

5. The Go code causes a stack growth. This stack unwind sees PC/SP "Y"
in the cgocall frame. Since the arguments are dead at "Y", they are
not adjusted.

6. The Go code returns to cgocallbackg1, which calls reentersyscall
with the recorded saved PC/SP "X", so "X" gets stashed back into
gp.syscallpc/sp.

7. GC scans the stack. It sees there's a saved syscall PC/SP, so it
starts the traceback at PC/SP "X". At "X" the arguments are considered
live, so it scans them, but since they weren't adjusted, the pointers
are bad, so it panics.

This issue started as of commit ca4089ad, when the compiler stopped
marking arguments as live for the whole function.

Since this is a variable liveness issue, fix it by adding KeepAlive
calls that keep the arguments live across this whole time warp.

The existing issue7978 test has all of the infrastructure for testing
this except that it's currently up to chance whether a stack growth
happens in the callback (it currently only happens on the
linux-amd64-noopt builder, for example). Update this test to force a
stack growth, which causes it to fail reliably without this fix.

Fixes #17785.

Change-Id: If706963819ee7814e6705693247bcb97a6f7adb8
Reviewed-on: https://go-review.googlesource.com/33710Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarKeith Randall <khr@golang.org>
      f6bff1d5
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7