go: runtime: failures in TestCtrlHandler with "could not read stdout: EOF" on windows-arm64

Okay, thanks! Yeah, if it is called via cgocallback, it would look like a regular Go function, so blocking the function probably will work.

Implementing preemptM shouldn’t be hard. But I agree we probably don’t do it in the freeze.

You’re spot on. That seems to be the problem. What happens is, I’m pretty sure, this:

• When a “signal” arrives to our ConsoleCtrlHandler, and it is a signal that would terminate the process if we returned (which is exactly what we’re sending here), we post the signal (through another p) and then the (arbitrary) thread that handled the signal goes to sleep (real sleep, like stdcall1(_Sleep, uintptr(_INFINITE)))
• If a GC starts here and decides to preempt alll p’s it will try to preempt the m that is now blocked by calling preemptM from the preeptone function.
• But on arm64, preemptMSupported is not true, and there’s a TODO: Implement call injection in the beginning of preemptM(). So, nothing happens, we continue to wait for non-preempted p:s to proclaim themselves idle forever
• Meanwhile, the world is stopped, so the program is essentially one big idle-loop.

This happens when a GC is needed between the signal has arrived and the signal is processed by the little test program, and would not happen on amd64 as preemptM is implemented there. For unknown reasons, GC sometimes happen early and there’n no neeed for GC between the signal arrives and the program is terminated in a normal way, sometimes a GC is needed in the “bad” situation.

I see three solutions:

1. just disable the test on arm64/windows until the TODO can be addressed
2. Both disable the test and also make sure to not try to handle terminate-signals on arm64, as it will inevitably be flaky
3. implement preemptM on arm64, which I’m unsure of how hard it would be

I suggest 2 for 1.18, 3 for 1.19. Any input is welcome.