Commit b08156cd authored by Russ Cox's avatar Russ Cox

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
parent e509bbc9
......@@ -2525,8 +2525,29 @@ runfinq(void)
uint32 framesz, framecap, i;
Eface *ef, ef1;
// This function blocks for long periods of time, and because it is written in C
// we have no liveness information. Zero everything so that uninitialized pointers
// do not cause memory leaks.
f = nil;
fb = nil;
next = nil;
frame = nil;
framecap = 0;
framesz = 0;
i = 0;
ef = nil;
ef1.type = nil;
ef1.data = nil;
// force flush to memory
USED(&f);
USED(&fb);
USED(&next);
USED(&framesz);
USED(&i);
USED(&ef);
USED(&ef1);
for(;;) {
runtime·lock(&gclock);
fb = finq;
......@@ -2581,6 +2602,16 @@ runfinq(void)
finc = fb;
runtime·unlock(&gclock);
}
// Zero everything that's dead, to avoid memory leaks.
// See comment at top of function.
f = nil;
fb = nil;
next = nil;
i = 0;
ef = nil;
ef1.type = nil;
ef1.data = nil;
runtime·gc(1); // trigger another gc to clean up the finalized objects, if possible
}
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment