Skip to content

G
go
Switch branch/tag
  1. 18 Jun, 2015 13 commits
  3. 17 Jun, 2015 22 commits
  5. 16 Jun, 2015 5 commits
    • Robert Griesemer's avatar
      go/types: don't export gcCompatibilityMode flag · d3e8a361
      Robert Griesemer authored 
      This flag is not needed in the std repo because we don't have
tests requiring it. Remove it before it's frozen into the API.

Change-Id: I18b861eea146ad67e7a3c26ee8be681d8065ef12
Reviewed-on: https://go-review.googlesource.com/11150Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      d3e8a361
    • Michael Hudson-Doyle's avatar
      cmd/link: when reading symbols from a shared library, allow duplicates when they are both in bss · a5f57d79
      Michael Hudson-Doyle authored 
      This makes the behaviour match what happens when duplicate symbols are read
from regular object files and fixes errors about cgoAlwaysFalse when linking
an executable that uses cgo against a shared library.

Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063
Reviewed-on: https://go-review.googlesource.com/11117Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a5f57d79
    • David du Colombier's avatar
      os: skip TestHostname on Plan 9 · b1be1217
      David du Colombier authored 
      TestHostname was re-enabled in CL 10753.
However, on Plan 9 the hostname is not obtained
by executing a "hostname" command, but by reading
the #c/sysname file.

Change-Id: I80c0e303f4983fe39ceb300ad64e2c4a8392b695
Reviewed-on: https://go-review.googlesource.com/11033
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      b1be1217
    • Austin Clements's avatar
      runtime: account for stack guard when shrinking the stack · 7387121d
      Austin Clements authored 
      Currently, when shrinkstack computes whether the halved stack
allocation will have enough room for the stack, it accounts for the
stack space that's actively in use but fails to leave extra room for
the stack guard space. As a result, *if* the minimum stack size is
small enough or the guard large enough, it may shrink the stack and
leave less than enough room to run nosplit functions. If the next
function called after the stack shrink is a nosplit function, it may
overflow the stack without noticing and overwrite non-stack memory.

We don't think this is happening under normal conditions right now.
The minimum stack allocation is 2K and the guard is 640 bytes. The
"worst case" stack shrink is from 4K (4048 bytes after stack barrier
array reservation) to 2K (2016 bytes after stack barrier array
reservation), which means the largest "used" size that will qualify
for shrinking is 4048/4 - 8 = 1004 bytes. After copying, that leaves
2016 - 1004 = 1012 bytes of available stack, which is significantly
more than the guard space.

If we were to reduce the minimum stack size to 1K or raise the guard
space above 1012 bytes, the logic in shrinkstack would no longer leave
enough space.

It's also possible to trigger this problem by setting
firstStackBarrierOffset to 0, which puts stack barriers in a debug
mode that steals away *half* of the stack for the stack barrier array
reservation. Then, the largest "used" size that qualifies for
shrinking is (4096/2)/4 - 8 = 504 bytes. After copying, that leaves
(2096/2) - 504 = 8 bytes of available stack; much less than the
required guard space. This causes failures like those in issue #11027
because func gc() shrinks its own stack and then immediately calls
casgstatus (a nosplit function), which overflows the stack and
overwrites a free list pointer in the neighboring span. However, since
this seems to require the special debug mode, we don't think it's
responsible for issue #11027.

To forestall all of these subtle issues, this commit modifies
shrinkstack to correctly account for the guard space when considering
whether to halve the stack allocation.

Change-Id: I7312584addc63b5bfe55cc384a1012f6181f1b9d
Reviewed-on: https://go-review.googlesource.com/10714Reviewed-by: default avatarKeith Randall <khr@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      7387121d
    • Austin Clements's avatar
      runtime: detect and print corrupted free lists · 5250279e
      Austin Clements authored 
      Issues #10240, #10541, #10941, #11023, #11027 and possibly others are
indicating memory corruption in the runtime. One of the easiest places
to both get corruption and detect it is in the allocator's free lists
since they appear throughout memory and follow strict invariants. This
commit adds a check when sweeping a span that its free list is sane
and, if not, it prints the corrupted free list and panics. Hopefully
this will help us collect more information on these failures.

Change-Id: I6d417bcaeedf654943a5e068bd76b58bb02d4a64
Reviewed-on: https://go-review.googlesource.com/10713Reviewed-by: default avatarKeith Randall <khr@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
      5250279e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7