Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: some programs broken on Wine after removing time compatibility hacks #34021

mvdan opened this issue Sep 2, 2019 · 3 comments


Copy link

@mvdan mvdan commented Sep 2, 2019

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
        /home/mvdan/tip/src/runtime/proc.go:152 +0x350 fp=0xc00003bfe0 sp=0xc00003bf60 pc=0x432500
        /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 I can provide a small reproducer if necessary, but I think the crash is pretty evident.

It looks like this was intentional as of 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:

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.

Copy link

@zx2c4 zx2c4 commented Sep 2, 2019

Afaict, this is fixed in upstream wine. Upgrade your wine. This is 1.14 material which means it's a long way off from release.

Copy link
Member Author

@mvdan mvdan commented Sep 2, 2019

Please read my detailed report above; I tested on Wine 4.15, which was released less than three days ago. Am I already out of date? :)

Copy link
Member Author

@mvdan mvdan commented Sep 2, 2019

Reverted the CL in question as of; my bad for forgetting the issue link in the commit message.

@mvdan mvdan closed this Sep 2, 2019
@golang golang locked and limited conversation to collaborators Sep 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants