Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: write barrier incorrect on wasm [1.11 backport] #30872

gopherbot opened this issue Mar 15, 2019 · 3 comments


None yet
2 participants
Copy link

commented Mar 15, 2019

@aclements requested issue #30871 to be considered for backport to the next 1.11 minor release.

@gopherbot, please backport to Go 1.12 and Go 1.11.


This comment has been minimized.

Copy link

commented Mar 15, 2019

Change mentions this issue: [release-branch.go1.11] runtime: fix write barrier on wasm


This comment has been minimized.

Copy link

commented Mar 19, 2019

Approved, re: #30873 (comment)


This comment has been minimized.

Copy link

commented Mar 19, 2019

Closed by merging 987e905 to release-branch.go1.11.

@gopherbot gopherbot closed this Mar 19, 2019

gopherbot pushed a commit that referenced this issue Mar 19, 2019

[release-branch.go1.11] runtime: fix write barrier on wasm
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
Run-TryBot: Austin Clements <>
Reviewed-by: Cherry Zhang <>
(cherry picked from commit d9db9e3)
Reviewed-by: Katie Hockman <>
TryBot-Result: Gobot Gobot <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.