os: TestPipeThreads failing sporadically on aix-ppc64

[pmur]

Go version

master

Output of go env in your module/workspace:

GOOS=aix

What did you do?

#build go.
go test os -test.run=TestPipeThreads -test.count=1

What did you see happen?

The tests fails consistently on aix systems with GOMAXPROC >= 8. It fails sporadically with smaller values, as is seen with aix-ppc64 CI. This CI log seems like the first of the recent failures. However, it is reproducible prior to the 1.23 release.

What did you expect to see?

The test passes consistently.

[gabyhelp]

Related Issues and Documentation

• os: Testhostname failing on aix-ppc64 CI builder #47945 (closed)
• runtime/pprof: failure in TestCPUProfileMultithreaded #36084 (closed)
• x/sys/unix: TestPassFD consistently failing in aix-ppc64 builder on release-branch.go1.12 #33982 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

The log https://build.golang.org/log/f58a9df223e4f6179ce1ec967c5ec8fa219cdefa shows 39 threads waiting in syscall.Read. The test expects those threads to quickly see that there is no data to read, and to fall back to using poll. There are 11 goroutines (not threads) sleeping waiting for poll to report that there is more data.

It's at least possible that with many CPUs the reading threads are being created faster than the kernel is deciding that there is no data to read and returning EAGAIN. It would be fine to skip the test on AIX with a comment pointing to this issue, as we've done with #19111 for Solaris.

[pmur]

That seems to agree with what I am seeing. I am curious why it started failing consistently during CI only recently. Does the scheduler restrict thread creation?

[cagedmantis]

cc @rsc @ianlancetaylor @bradfitz @griesemer

[gopherbot]

Change https://go.dev/cl/623817 mentions this issue: os: skip TestPipeThreads on aix

[ianlancetaylor]

The test uses the unusual runtime/debug.SetMaxThreads function to tell the scheduler to limit the number of threads that it creates.

But I have no idea why it started failing more frequently recently.