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: hangup in umtx_op system call when changing system clock #17168
Comments
I guess it's unlikely and the culprit stays in neighborhood. Can you run your snippet with GOTRACEBACK=all, twiddle the running system clock, and then send SIGABRT to the process? Hope it generates useful information for debugging.
|
Thanks for taking a look at this, Here is the trace:
|
It seems this issue is due to a change in the way the The tl;dr is that due to the way the runtime calls The relevant FreeBSD commit is 232144, which I think landed in the 10.0.0 release. For reference, this is the prototype for
And here is how we call it from
That is, Prior to the above mentioned FreeBSD commit, going back at least as far as release 8.0.0, After revision 232144, the above call will result in The relevant listing from
I modified I'm posting this wall of text here rather than mailing a change list because I'm sufficiently ignorant of the golang runtime that making even a small change makes me nervous, especially when it's difficult for me test against the full range of supported FreeBSD versions / architectures. If the maintainers don't mind beating acceptable code out of me via code review, just say the word and I'll mail a CL. |
@appleby, thanks for the investigation! Our FreeBSD minimum requirements are kinda undefined: https://golang.org/wiki/MinimumRequirements @ianlancetaylor, any interest in reviewing a CL if @appleby sends one? @adg, any opinions on which version(s) of FreeBSD we officially support? |
I'm happy to look at a CL, but do we know what happens when we pass a large Or we could decide to drop support for older versions of FreeBSD. I'm not a FreeBSD user myself so I have no opinion about that. |
My understanding is that 231989 was followed 3 days later by 232144, but the semantics of As far as I can tell, any version cut from a RELEASE branch will either ignore On the other hand, I believe this would be a breaking change for any system running an old STABLE or CURRENT cut after 231989 but before 232144. I don't know enough about FreeBSD releases to know whether any such releases actually exists. |
My svn-fu is weak, but it looks like none of the releng, release, or stable branches contain r231989 that do no also contain r232144. The earliest branches these revisions appear in are stable/10 and releng/10.0. I will spin up at least a couple of older FreeBSD VMs for testing before I mail the CL. It might take a day or two as I am behind a slow link, so downloading the images takes a while. |
CL https://golang.org/cl/30154 mentions this issue. |
CL https://golang.org/cl/31269 mentions this issue. |
…p1 on freebsd In FreeBSD 10.0, the _umtx_op syscall was changed to allow sleeping on any supported clock, but the default clock was switched from a monotonic clock to CLOCK_REALTIME. Prior to 10.0, the __umtx_op_wait* functions ignored the fourth argument to _umtx_op (uaddr1), expected the fifth argument (uaddr2) to be a struct timespec pointer, and used a monotonic clock (nanouptime(9)) for timeout calculations. Since 10.0, if callers want a clock other than CLOCK_REALTIME, they must call _umtx_op with uaddr1 set to a value greater than sizeof(struct timespec), and with uaddr2 as pointer to a struct _umtx_time, rather than a timespec. Callers can set the _clockid field of the struct _umtx_time to request the clock they want. The relevant FreeBSD commit: https://svnweb.freebsd.org/base?view=revision&revision=232144 Fixes #17168 Change-Id: I3dd7b32b683622b8d7b4a6a8f9eb56401bed6bdf Reviewed-on: https://go-review.googlesource.com/30154 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/31269
…p1 on freebsd In FreeBSD 10.0, the _umtx_op syscall was changed to allow sleeping on any supported clock, but the default clock was switched from a monotonic clock to CLOCK_REALTIME. Prior to 10.0, the __umtx_op_wait* functions ignored the fourth argument to _umtx_op (uaddr1), expected the fifth argument (uaddr2) to be a struct timespec pointer, and used a monotonic clock (nanouptime(9)) for timeout calculations. Since 10.0, if callers want a clock other than CLOCK_REALTIME, they must call _umtx_op with uaddr1 set to a value greater than sizeof(struct timespec), and with uaddr2 as pointer to a struct _umtx_time, rather than a timespec. Callers can set the _clockid field of the struct _umtx_time to request the clock they want. The relevant FreeBSD commit: https://svnweb.freebsd.org/base?view=revision&revision=232144 Fixes golang#17168 Change-Id: I3dd7b32b683622b8d7b4a6a8f9eb56401bed6bdf Reviewed-on: https://go-review.googlesource.com/30154 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/31269
Version: go1.6.2 freebsd/amd64
Environment:
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH=""
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GO15VENDOREXPERIMENT="1"
CC="cc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="clang++"
CGO_ENABLED="1"
When running the following code sample:
In between 5 second output intervals adjust the system time backwards and notice the output. FreeBSD is documented as an OS that supports monotonic timers so I would expect the output to happen 5 seconds after the last line. However, it waits until the system time catches up with the scheduled time. The code above works as expected on another OS that supports monotonic timers (Windows).
Also, I tried calling clock_gettime() directly with CLOCK_MONOTONIC on the same system and was able to get monotonic time. Based on the source of sys_freebsd_amd64.s it doesn't seem like clock_gettime() is used inside runtime·nanotime as in sys_linux_amd64.s.
The text was updated successfully, but these errors were encountered: