This may have started on or around CL 454836, but since this builder is slow and heavily backlogged we don't have a clean bisection in the dashboard runs.

It appears that something in either the toolchain or the test process itself is failing to terminate properly. However, due to #53201 I can't even tell which process is hung.

@golang/release, can we prioritize a fix for #53201 to unblock investigation of this issue?

(CC @golang/runtime @golang/ios)

Since ios-arm64 is not a first class port, I'd like the iOS maintainers to spend at least some time investigating before we discuss prioritizing #53201.

Could you maybe clarify what needs to be investigated? It is not entirely clear after a large number of CLs are landed.

Essentially, see why the tests are hanging. archive/tar is the first test to run, so I suspect the port is completely broken.

It is not always the first test timed out (although it seems the case in a few most recent runs). https://build.golang.org/log/fe7dc38047bccedcf67640847ff602864fabc40b includes a few successful tests before hanging.

For ones who have access to the builder, would it be possible to see which process(es) hang, and would it be possible to send it a SIGQUIT and get a stack dump? Thanks.

Based on what I saw from the Corellium dashboard, the Go team has admin access to these builders (although I don't know how it is access from the Go team side)

@cherrymui, could you help me understand exactly what you expect me to do in which steps? Do you mean to kill the builtlet process and share the core dump file?

I'm not familiar with the builder infrastructure, so I don't know exactly. If you can log in to the builder machine/VM that is running the build, maybe run command like ps or top to see which processes are running, and send a SIGQUIT to a long-running one?

But before we spend more time on this, I'd like to hear some answer about the meta-question: if this is really due to cgo not enabled, do we really want to support non-cgo programs on iOS? If the answer is no, cmd/dist shouldn't disable cgo. If the answer is yes, maybe we want to support internal linking, so it is actually pure Go.

would it be possible to see which process(es) hang, and would it be possible to send it a SIGQUIT and get a stack dump?

That is exactly why #53201 is relevant. The buildlet should be sending SIGQUIT itself in case of timeouts (on all platforms that support it, not just ios), but today does not seem to be doing so.

Change https://go.dev/cl/463739 mentions this issue: cmd/dist: leave cgo enabled if external linking is required

Is this fixed?

This is indeed fixed by CL 463739, which re-enables cgo when building cmd on this platform.

I suspect that it was related to some iffy behavior in runtime/cgo on the ios/arm64 platform (filed as #58225), although there may be other issues involved as well.