TestTinyAllocIssue37262 assumes that all of its allocations will come
from the same tiny allocator (that is, the same P), and that nothing
else will allocate from that tiny allocator while it's running. It can
fail incorrectly if these assumptions aren't met.
Fix this potential test flakiness by disabling preemption during this
test.
As far as I know, this has never happened on the builders. It was
found by mayMoreStackPreempt.
Change-Id: I59f993e0bdbf46a9add842d0e278415422c3f804
Reviewed-on: https://go-review.googlesource.com/c/go/+/366994
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
escapeSink = nil
return x
}
+
+// Acquirem blocks preemption.
+func Acquirem() {
+ acquirem()
+}
+
+func Releasem() {
+ releasem(getg().m)
+}
runtime.GC()
runtime.GC()
+ // Disable preemption so we stay on one P's tiny allocator and
+ // nothing else allocates from it.
+ runtime.Acquirem()
+
// Make 1-byte allocations until we get a fresh tiny slot.
aligned := false
for i := 0; i < 16; i++ {
}
}
if !aligned {
+ runtime.Releasem()
t.Fatal("unable to get a fresh tiny slot")
}
tinyByteSink = nil
tinyUint32Sink = nil
tinyObj12Sink = nil
+
+ runtime.Releasem()
}
func TestPageCacheLeak(t *testing.T) {