context: BenchmarkWithTimeout/concurrency tests hang if -test.timeout=30m used on linux/{amd64,ppc64le,...}

[laboger]

What version of Go are you using (go version)?

$ go version
go version devel +63fd764502 Wed Nov 4 23:24:22 2020 +0000 linux/ppc64le
go version devel +34c09695db Thu Nov 5 15:16:57 2020 +0000 linux/amd64
Hangs on both. Didn't try any others.

Does this issue reproduce with the latest release?

Does not hang in go 11.5.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

What did you do?

cd context
go test -test.bench=Timeout -test.timeout=30m -test.count=100

What did you expect to see?

Benchmarks complete with benchmark timing output.

What did you see instead?

One of the Timeout benchmarks hangs and the benchmarks do not finish.
go test -test.bench=Timeout -test.timeout=30m -test.count=100
goos: linux
goarch: ppc64le
pkg: context
BenchmarkWithTimeout/concurrency=40-16 317062 3244 ns/op
BenchmarkWithTimeout/concurrency=40-16 318670 3236 ns/op
BenchmarkWithTimeout/concurrency=40-16 383541 3008 ns/op
BenchmarkWithTimeout/concurrency=40-16 372940 3123 ns/op
BenchmarkWithTimeout/concurrency=40-16 (stops here.... )
Same behavior on amd64.

Trying some earlier commits, I found one from early September that does not hang but more experiments needed.

[laboger]

I got this test to hang on one system without setting the timeout option.

[erifan]

This is just the same issue with #42237

[dmitshur]

Issue #42237 is about OpenBSD specifically, and it will be resolved with #42426.

Reopening this since this is about linux/amd64 and linux/ppc64le, so it should be investigated separately, although it may be related in some way.

[cagedmantis]

/cc @Sajmani @bradfitz

[bcmills]

This probably has the same root cause as #42424.

[laboger]

This is not happening for me with the latest master on ppc64le.
My testing shows that it was fixed by CL 267257 and as you suspected that means it was probably introduced by CL 232298.
Also verified amd64 is fixed with CL 267257.

[bcmills]

@laboger, thanks for verifying!