-
Russ Cox authored
This is the same check we use during stack copying. The check cannot be applied to C stack frames, even though we do emit pointer bitmaps for the arguments, because (1) the pointer bitmaps assume all arguments are always live, not true of outputs during the prologue, and (2) the pointer bitmaps encode interface values as pointer pairs, not true of interfaces holding integers. For the rest of the frames, however, we should hold ourselves to the rule that a pointer marked live really is initialized. The interface scanning already implicitly checks this because it interprets the type word as a valid type pointer. This may slow things down a little because of the extra loads. Or it may speed things up because we don't bother enqueuing nil pointers anymore. Enough of the rest of the system is slow right now that we can't measure it meaningfully. Enable for now, even if it is slow, to shake out bugs in the liveness bitmaps, and then decide whether to turn it off for the Go 1.3 release (issue 7650 reminds us to do this). The new m->traceback field lets us force printing of fp= values on all goroutine stack traces when we detect a bad pointer. This makes it easier to understand exactly where in the frame the bad pointer is, so that we can trace it back to a specific variable and determine what is wrong. Update #7650 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80860044
5a23a7e5