Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.
This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.
Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.
Fixes #44610.
Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>