• Russ Cox's avatar
    runtime: enable 'bad pointer' check during garbage collection of Go stack frames · 5a23a7e5
    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
runtime.c 7.6 KB