You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
package main
import (
"fmt"
"runtime"
)
var sink *[20]byte
func f() (x [20]byte) {
// Force x to be allocated on the heap.
sink = &x
sink = nil
// Go to deferreturn after the panic below.
defer func() {
recover()
}()
// This call collects the heap-allocated version of x (!)
runtime.GC()
// Allocate that same object again and clobber it.
y := new([20]byte)
for i := 0; i < 20; i++ {
y[i] = 99
}
// Make sure y is heap allocated.
sink = y
panic(nil)
// After the recover we reach the deferreturn, which
// copies the heap version of x back to the stack.
// It gets the pointer to x from a stack slot that was
// not marked as live during the call to runtime.GC().
}
func main() {
x := f()
for _, v := range x {
if v != 0 {
fmt.Printf("%v\n", x)
panic("bad")
}
}
}
This program works in go1.2.2 but panics in later versions (go.1.3.3 through tip). I've labeled in 1.7maybe because it's not like we're breaking something that used to work.
Control flow only reaches the (non-panic) return point because of a recover() in a defer.
The use of &x is implicit at the return point.
The fix may be as simple as marking &v as live throughout the function for all return variables. We could probably restrict it to only functions that defer.
The experiment "clobberdead" clobbers all pointer fields that the
compiler thinks are dead, just before and after every safepoint.
Useful for debugging the generation of live pointer bitmaps.
Helped find the following issues:
Update #15936
Update #16026
Update #16095
Update #18860
Change-Id: Id1d12f86845e3d93bae903d968b1eac61fc461f9
Reviewed-on: https://go-review.googlesource.com/23924
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I've found a case where we don't generate live variable bitmaps correctly (using https://go-review.googlesource.com/c/23924/).
This program works in go1.2.2 but panics in later versions (go.1.3.3 through tip). I've labeled in 1.7maybe because it's not like we're breaking something that used to work.
See #16026.
The bug I think is a combination of:
The fix may be as simple as marking &v as live throughout the function for all return variables. We could probably restrict it to only functions that defer.
@aclements
The text was updated successfully, but these errors were encountered: