runtime: TestCgoLockOSThreadExit failures with `WaitDelay expired`

[gopherbot]

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit" && `WaitDelay expired` && date < "2023-03-01"

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestCgoLockOSThreadExit (33.56s)
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadMain (1.426881411s): ok
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadAlt: exec: WaitDelay expired before I/O complete

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit"

2022-12-01 21:00 linux-mips-rtrk go@93587d35 runtime.TestCgoLockOSThreadExit (log)

--- FAIL: TestCgoLockOSThreadExit (33.56s)
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadMain (1.426881411s): ok
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadAlt: exec: WaitDelay expired before I/O complete

— watchflakes

[prattmic]

cc @golang/mips

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit"

2022-12-16 17:12 openbsd-amd64-71 go@f4b42f5c runtime.TestCgoLockOSThreadExit (log)

--- FAIL: TestCgoLockOSThreadExit (0.00s)
    crash_test.go:58: /tmp/workdir/tmp/go-build3915581810/testprogcgo.exe LockOSThreadMain failed to start: context deadline exceeded

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit"

2023-01-24 19:18 dragonfly-amd64-622 go@27500d88 runtime.TestCgoLockOSThreadExit (log)

--- FAIL: TestCgoLockOSThreadExit (1.61s)
    crash_test.go:58: /tmp/workdir/tmp/go-build3735151313/testprogcgo.exe LockOSThreadMain (61.642428ms): ok
    crash_test.go:58: /tmp/workdir/tmp/go-build3735151313/testprogcgo.exe LockOSThreadAlt: exit status 1
    proc_test.go:988: want "OK\n", got "sub thread still running\n"

— watchflakes

[bcmills]

This failure mode does not appear to be platform-dependent — I think it's just a timing-sensitive test. Probably needs some kind of more explicit synchronization.

[bcmills]

Hmm. Actually, there are three different failure modes here:

• The openbsd-amd64-71 failure is runtime: test timeouts on openbsd-.*-71 builders #57585.
• The dragonfly-amd64-622 failure looks like a timing-sensitive behavior in the test — it only waits for 100ms before arbitrarily failing if the thread's destructor hasn't run yet.
• The linux-mips-rtrk failure is something different — the I/O from the test process took longer than we expected to flush.