go version devel +03ac39ce5e Mon Sep 2 12:57:37 2019 +0000 linux/amd64

I've started seeing panics like the one below when running some of my tests via GOOS=windows go test -exec=wine:

fatal error: nanotime returning zero

goroutine 1 [running, locked to thread]:
runtime.throw(0x60406f, 0x17)
        /home/mvdan/tip/src/runtime/panic.go:774 +0x79 fp=0xc00003bf60 sp=0xc00003bf30 pc=0x4309f9
runtime.main()
        /home/mvdan/tip/src/runtime/proc.go:152 +0x350 fp=0xc00003bfe0 sp=0xc00003bf60 pc=0x432500
runtime.goexit()
        /home/mvdan/tip/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc00003bfe8 sp=0xc00003bfe0 pc=0x45e2e1
exit status 2

If anyone wants to reproduce the crash, the Go package in question is https://github.com/mvdan/sh/tree/6af96bc17993a990fcd2c341c83a168a3158daa1/interp. I can provide a small reproducer if necessary, but I think the crash is pretty evident.

It looks like this was intentional as of https://go-review.googlesource.com/c/go/+/191759. The CL reads:

1. Wine is useful and developers will appreciate being able to debug stuff with it.

This gets a big +1 from me, of course :)

(1) has been handled for some time by Wine with the introduction of the commit entitled "ntdll: Create thread to update user_shared_data time values when necessary".

Unfortunately, the commit message didn't include a direct link to said patch or fixed bug. All I could find is this patch maintained as part of wine-staging: https://github.com/wine-staging/wine-staging/blob/a46b9ff3dcb51398cd6626f7090d8885844e1b5b/patches/ntdll-User_Shared_Data/0003-ntdll-Create-thread-to-update-user_shared_data-time-.patch

I can further prove this; the crash happens on vanilla Wine 4.15, but doesn't happen on Wine 4.15 staging.

So I don't think that Wine has handled this for some time, as the CL describes. At best, a patch has been available on wine-staging since 2017, but most users don't run wine-staging. I would personally prefer sticking to vanilla Wine, as it's more stable, and I've had no reason to use staging patches until now.

This is not an issue to report a regression and demand a revert; I understand the code in the runtime package was a hack, and that in the long term we're better off without it. However, I think we should be aware that this will break a non-trivial amount of users. And, even if Wine 4.16 shipped tomorrow with a stable fix, it would at least be a year or two before most Linux users are using that newer Wine version.

At a minimum, I think we should keep an issue like this one open, to quickly point confused users at a temporary workaround. I'm all ears on that front; I can run wine-staging for now, but that's not an ideal solution.