Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\dev\cygwin64\tmp\go-build1333133088=/tmp/go-build -gno-record-gcc-switches
It might be relevant that the os thread lock is permanently grabbed by the main driver thread, but lockOSThread is nonetheless called later when the syscall.Syscall family of functions is used.
lockOSThread locks the goroutine to the current OS thread, which is not necessarily the main thread. So the lockOSThread around syscall.Syscall does not guarantee the syscall is made on the main thread.
There's a comment at the top of the code that shows a script to restart the program in a loop continuously until it errors out. It was by using such a script that it took around a minute to trigger the bug.
In that comment I gave a bash script for running the program in a loop (I'm using cygwin). The batch file version would be:
if %errorlevel% == 1 (exit)
Today, on two different computers (both Windows 10 version 19042.1165), after compiling with gotip, the fastest it printed the message was 2s, the slowest was 5m50s, the average was around 3m. Several times slower than when I tested it just before originally posting this bug, for whatever reason.
( Edit: I had a paragraph here about a version of the repro code that triggers the bug faster, but I just discovered that while on one computer, it triggers the bug reliably within 10 seconds, on a different computer it's not triggered faster at all. I'll leave it here for completeness, but it may or may not be useful to you: http://theinternetftw.com/code/shinyrepro2.zip )