Skip to content

G
golang
Switch branch/tag
  1. 11 Apr, 2019 2 commits
  3. 08 Apr, 2019 3 commits
  5. 05 Apr, 2019 2 commits
  7. 27 Mar, 2019 1 commit
  9. 19 Mar, 2019 1 commit
    • Austin Clements's avatar
      [release-branch.go1.11] runtime: fix write barrier on wasm · 987e905b
      Austin Clements authored 
      The current wasm write barrier implementation incorrectly implements
the "deletion" part of the barrier. It correctly greys the new value
of the pointer, but rather than also greying the old value of the
pointer, it greys the object containing the slot (which, since the old
value was just overwritten, is not going to contain the old value).

This can lead to unmarked, reachable objects.

Often, this is masked by other marking activity, but one specific
sequence that can lead to an unmarked object because of this bug is:

1. Initially, GC is off, object A is reachable from just one pointer
in the heap.

2. GC starts and scans the stack of goroutine G.

3. G copies the pointer to A on to its stack and overwrites the
pointer to A in the heap. (Now A is reachable only from G's stack.)

4. GC finishes while A is still reachable from G's stack.

With a functioning deletion barrier, step 3 causes A to be greyed.
Without a functioning deletion barrier, nothing causes A to be greyed,
so A will be freed even though it's still reachable from G's stack.

This CL fixes the wasm write barrier.

Fixes #30872.

Change-Id: I8a74ee517facd3aa9ad606e5424bcf8f0d78e754
Reviewed-on: https://go-review.googlesource.com/c/go/+/167743
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
(cherry picked from commit d9db9e32)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167746Reviewed-by: 's avatarKatie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      987e905b
  11. 14 Mar, 2019 3 commits
  13. 27 Feb, 2019 1 commit
  15. 26 Feb, 2019 1 commit
  17. 25 Feb, 2019 1 commit
  19. 22 Feb, 2019 2 commits
  21. 01 Feb, 2019 4 commits
  23. 23 Jan, 2019 5 commits
  25. 14 Jan, 2019 1 commit
  27. 07 Jan, 2019 1 commit
  29. 04 Jan, 2019 4 commits
  31. 03 Jan, 2019 1 commit
  33. 19 Dec, 2018 1 commit
    • Michael Anthony Knyszek's avatar
      [release-branch.go1.11] runtime: don't clear lockedExt on locked M when G exits · f500f13d
      Michael Anthony Knyszek authored 
      When a locked M has its G exit without calling UnlockOSThread, then
lockedExt on it was getting cleared. Unfortunately, this meant that
during P handoff, if a new M was started, it might get forked (on
most OSes besides Windows) from the locked M, which could have kernel
state attached to it.

To solve this, just don't clear lockedExt. At the point where the
locked M has its G exit, it will also exit in accordance with the
LockOSThread API. So, we can safely assume that it's lockedExt state
will no longer be used. For the case of the main thread where it just
gets wedged instead of exiting, it's probably better for it to keep
the locked marker since it more accurately represents its state.

Fixed #28986.

Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f
Reviewed-on: https://go-review.googlesource.com/c/155117
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      f500f13d
  35. 17 Dec, 2018 1 commit
  37. 14 Dec, 2018 5 commits