Skip to content

G
go
Switch branch/tag
  1. 23 May, 2017 10 commits
    • Hiroshi Ioka's avatar
      cmd/cgo: support indirect macro expansion for string · dd61aa55
      Hiroshi Ioka authored 
      Current code cannot handle string #define macros if those macros are
defined via other macros. This CL solve the issue.

Updates #18720

Change-Id: Ibed0773d10db3d545bb246b97e81c0d19e3af3d5
Reviewed-on: https://go-review.googlesource.com/41312Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      dd61aa55
    • Brad Fitzpatrick's avatar
      cmd/go: include GOARM and GO386 in computed build ID · 1b53f15e
      Brad Fitzpatrick authored 
      Now:
$ GOARCH=arm GOARM=5 go install -x cmd/go
... followed by:
$ GOARCH=arm GOARM= go install -x cmd/go

... actually does work. Previously the second "go install" would reuse
the cached binaries from the GOARM=5 command and not rebuild.
(Or vice versa from GOARM= to GOARM=5)

And do the same for GO386.

Fixes #9737

Change-Id: I9630aab34d06465d5033e6743dfe6592c8247aa0
Reviewed-on: https://go-review.googlesource.com/43855
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      1b53f15e
    • Wade Simmons's avatar
      crypto/rand: only read necessary bytes for Int · 8a2553e3
      Wade Simmons authored 
      We only need to read the number of bytes required to store the value
"max - 1" to generate a random number in the range [0, max).

Before, there was an off-by-one error where an extra byte was read from
the io.Reader for inputs like "256" (right at the boundary for a byte).
There was a similar off-by-one error in the logic for clearing bits and
thus for any input that was a power of 2, there was a 50% chance the
read would continue to be retried as the mask failed to remove a bit.

Fixes #18165.

Change-Id: I548c1368990e23e365591e77980e9086fafb6518
Reviewed-on: https://go-review.googlesource.com/43891Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      8a2553e3
    • Austin Clements's avatar
      runtime: remove unused copies of special stack guards · 9f03e895
      Austin Clements authored 
      There are two copies each of the stackPreempt/_StackPreempt and
stackFork/_StackFork constants. Remove the ones left over from C that
are no longer used.

Change-Id: I849604c72c11e4a0cb08e45e9817eb3f5a6ce8ba
Reviewed-on: https://go-review.googlesource.com/43638Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      9f03e895
    • Austin Clements's avatar
      runtime: fix stackCache=0 debug mode · 47542520
      Austin Clements authored 
      Setting stackCache to 0 to disable stack caches for debugging hasn't
worked for a long time. It causes stackalloc to fall back to full span
allocation, round sub-page stacks down to 0 pages, and blow up.

Fix this debug mode so it disables the per-P caches, but continues to
use the global stack pools for small stacks, which correctly handle
sub-page stacks. While we're here, rename stackCache to stackNoCache
so it acts like the rest of the stack allocator debug modes where "0"
is the right default value.

Fixes #17291.

Change-Id: If401c41cee3448513cbd7bb2e9334a8efab257a7
Reviewed-on: https://go-review.googlesource.com/43637Reviewed-by: default avatarKeith Randall <khr@golang.org>
      47542520
    • Austin Clements's avatar
      runtime: fix stackFromSystem returning memory · 8a1c5b2e
      Austin Clements authored 
      The stackFromSystem debug mode has two problems:

1) It rounds the stack allocation to _PageSize. If the physical page
size is >8K, this can cause unmapping the memory later to either
under-unmap or over-unmap.

2) It doesn't return the rounded-up allocation size to its caller, so
when we later unmap the memory, we may pass the wrong length.

Fix these problems by rounding the size up to the physical page size
and putting that rounded-up size in the returned stack bounds.

Fixes #17289.

Change-Id: I6b854af3b06bb16e3750798397bb5e2a722ec1cb
Reviewed-on: https://go-review.googlesource.com/43636Reviewed-by: default avatarKeith Randall <khr@golang.org>
      8a1c5b2e
    • Chris Broadfoot's avatar
      doc: document go1.8.2 and go1.7.6 · e16944da
      Chris Broadfoot authored 
      Change-Id: I2ed2e8c4890a65288cf3066ebe3c1d9a16fb4c05
Reviewed-on: https://go-review.googlesource.com/43990Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      e16944da
    • Austin Clements's avatar
      runtime: don't corrupt arena bounds on low mmap · e5a5c03f
      Austin Clements authored 
      If mheap.sysAlloc doesn't have room in the heap arena for an
allocation, it will attempt to map more address space with sysReserve.
sysReserve is given a hint, but can return any unused address range.
Currently, mheap.sysAlloc incorrectly assumes the returned region will
never fall between arena_start and arena_used. If it does,
mheap.sysAlloc will blindly accept the new region as the new
arena_used and arena_end, causing these to decrease and make it so any
Go heap above the new arena_used is no longer considered part of the
Go heap. This assumption *used to be* safe because we had all memory
between arena_start and arena_used mapped, but when we switched to an
arena_start of 0 on 32-bit, it became no longer safe.

Most likely, we've only recently seen this bug occur because we
usually start arena_used just above the binary, which is low in the
address space. Hence, the kernel is very unlikely to give us a region
before arena_used.

Since mheap.sysAlloc is a linear allocator, there's not much we can do
to handle this well. Hence, we fix this problem by simply rejecting
the new region if it isn't after arena_end. In this case, we'll take
the fall-back path and mmap a small region at any address just for the
requested memory.

Fixes #20259.

Change-Id: Ib72e8cd621545002d595c7cade1e817cfe3e5b1e
Reviewed-on: https://go-review.googlesource.com/43870Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      e5a5c03f
    • Joe Richey joerichey@google.com's avatar
      crypto/rand: use blocking getrandom call on Linux when supported · 95d991d3
      Joe Richey joerichey@google.com authored 
      By changing getRandomLinux to immediately use the getrandom() syscall
without GRND_NONBLOCK, we now only fall back to reading from
/dev/urandom on Linux if the kernel does not support the getrandom()
syscall. This means reads for crypto/rand will now block if the kernel
has insufficient entropy on Linux kernels after v3.16.

Before, if the kernel had insufficient entropy, it would fall back to
reading from /dev/urandom. This would potentially return predictable
data.

Fixes #19274

Change-Id: I1cb081ce2f3096f18ad2820e52ecdbd993dc2afc
Reviewed-on: https://go-review.googlesource.com/43852Reviewed-by: default avatarFilippo Valsorda <hi@filippo.io>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      95d991d3
    • Alex Brainman's avatar
      os/exec: ignore some pipe write errors on windows · f3f29d1d
      Alex Brainman authored 
      This change is windows version of CL 12152.
It also extends test to cover scenarios reported on issue #20445.
Some source files copied and renamed to make code clearer.

Fixes #20445

Change-Id: Idd2f636f27c6bd5cfe98017ba2df911358263382
Reviewed-on: https://go-review.googlesource.com/43910
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      f3f29d1d
  3. 22 May, 2017 14 commits
  5. 20 May, 2017 2 commits
  7. 19 May, 2017 12 commits
  9. 18 May, 2017 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7