Skip to content

G
golang
Switch branch/tag
  1. 09 Jul, 2018 16 commits
  3. 08 Jul, 2018 3 commits
  5. 07 Jul, 2018 4 commits
    • Austin Clements's avatar
      runtime: handle g0 stack overflows gracefully · 78561c4a
      Austin Clements authored 
      Currently, if the runtime overflows the g0 stack on Windows, it leads
to an infinite recursion:

1. Something overflows the g0 stack bounds and calls morestack.

2. morestack determines it's on the g0 stack and hence cannot grow the
stack, so it calls badmorestackg0 (which prints "fatal: morestack on
g0") followed by abort.

3. abort performs an INT $3, which turns into a Windows
_EXCEPTION_BREAKPOINT exception.

4. This enters the Windows sigtramp, which ensures we're on the g0
stack and calls exceptionhandler.

5. exceptionhandler has a stack check prologue, so it determines that
it's out of stack and calls morestack.

6. goto 2

Fix this by making the exception handler avoid stack checks until it
has ruled out an abort and by blowing away the stack bounds in
lastcontinuehandler before we print the final fatal traceback (which
itself involves a lot of stack bounds checks).

Fixes #21382.

Change-Id: Ie66e91f708e18d131d97f22b43f9ac26f3aece5a
Reviewed-on: https://go-review.googlesource.com/120857
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      78561c4a
    • Austin Clements's avatar
      runtime: account for guard zone in Windows stack size · d6b56bb3
      Austin Clements authored 
      Windows includes an 8K guard in system-allocated thread stacks, which
we currently don't account for when setting the g0 stack bounds. As a
result, if we do overflow the g0 stack bounds, we'll get a
STATUS_GUARD_PAGE_VIOLATION exception, which we're not expecting.

Fix the g0 stack bounds to include a total of 16K of slop to account
for this 8K guard.

Updates #21382.

Change-Id: Ia89b741b1413328e4681a237f5a7ee645531fe16
Reviewed-on: https://go-review.googlesource.com/122516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      d6b56bb3
    • Austin Clements's avatar
      runtime: fix abort handling on Windows · 7001ac53
      Austin Clements authored 
      On Windows, the IP recorded in the breakpoint exception caused by
runtime.abort is actually one byte after the INT3, unlike on UNIX
OSes. Account for this in isgoexception.

It turns out TestAbort was "passing" on Windows anyway because abort
still caused a fatal panic, just not the one we were expecting. This
CL tightens this test to check that the runtime specifically reports a
breakpoint exception.

Fixing this is related to #21382, since we use runtime.abort in
reporting g0 stack overflows, and it's important that we detect this
and not try to handle it.

Change-Id: I66120944d138eb80f839346b157a3759c1019e34
Reviewed-on: https://go-review.googlesource.com/122515
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      7001ac53
    • Ben Shi's avatar
      cmd/compile: fix a bug in 386 backend · f5d48631
      Ben Shi authored 
      The ADDLmodify/SUBLmodify/ANDLmodify/ORLmodify/XORLmodify should
have clobberFlags set to true.

Change-Id: Ie447d536db51334eddc70c00a722647282186a69
Reviewed-on: https://go-review.googlesource.com/122556
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      f5d48631
  7. 06 Jul, 2018 11 commits
  9. 05 Jul, 2018 3 commits
  11. 04 Jul, 2018 3 commits