runtime: fix memory leak in runfinq
One reason the sync.Pool finalizer test can fail is that this function's ef1 contains uninitialized data that just happens to point at some of the old pool. I've seen this cause retention of a single pool cache line (32 elements) on arm. Really we need liveness information for C functions, but for now we can be more careful about data in long-lived C functions that block. LGTM=bradfitz, dvyukov R=golang-codereviews, bradfitz, dvyukov CC=golang-codereviews, iant, khr https://golang.org/cl/72490043
Showing
Please register or sign in to comment