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: TestCgoExternalThreadSIGPROF fails on netbsd7-amd64 #14052

Closed
rillig opened this issue Jan 21, 2016 · 6 comments
Closed

runtime: TestCgoExternalThreadSIGPROF fails on netbsd7-amd64 #14052

rillig opened this issue Jan 21, 2016 · 6 comments

Comments

@rillig
Copy link
Contributor

rillig commented Jan 21, 2016

Go version: devel from https://go-review.googlesource.com/#/c/18776/3
Platform: netbsd7-amd64

When I bootstrap the compiler using the following command, it fails.

$ (cd src && env GOROOT_BOOTSTRAP=$HOME/pkg/go GOROOT_FINAL=$HOME/godev bash ./all.bash)

The output is:

ok      regexp  1.385s
ok      regexp/syntax   0.956s
--- FAIL: TestCgoExternalThreadSIGPROF (0.02s)
        crash_cgo_test.go:96: expected "OK\n", but got:
--- FAIL: TestSignalExitStatus (0.01s)
        crash_unix_test.go:145: test program succeeded unexpectedly
FAIL
FAIL    runtime 93.289s
ok      runtime/debug   0.359s
ok      runtime/internal/atomic 0.376s
@bradfitz
Copy link
Contributor

Is this a regression from Go 1.5, or a breakage from NetBSD 6 to NetBSD 7?

@bradfitz bradfitz added this to the Go1.6Maybe milestone Jan 21, 2016
@ianlancetaylor
Copy link
Contributor

I have a patch for TestCgoExternalThreadSIGPROF that I will send soon.

Coincidentally I opened issue #14063 earlier today for TestSignalExitStatus. I have no idea what is going on with that one.

@gopherbot
Copy link

CL https://golang.org/cl/18815 mentions this issue.

gopherbot pushed a commit that referenced this issue Jan 21, 2016
On NetBSD a signal handler returns to the kernel by calling the
setcontext system call with the context passed to the signal handler.
The implementation of runtime·sigreturn_tramp for amd64, copied from the
NetBSD libc, expects that context address to be in r15.  That works in
the NetBSD libc because r15 is preserved across the call to the signal
handler.  It fails in the Go library because r15 is not preserved.
There are various ways to fix this; this one uses the simple approach,
essentially identical to the one in the NetBSD libc, of preserving r15
across the signal handler proper.

Looking at the code for 386 and arm suggests that they are OK.  However,
I have not actually tested them.

Update #14052.

Change-Id: I2b516b1d05fe5d3b8911e65ca761d621dc37fa1b
Reviewed-on: https://go-review.googlesource.com/18815
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@rillig
Copy link
Contributor Author

rillig commented Jan 22, 2016

@bradfitz

On go1.5.3 netbsd7 amd64 it looks similar, but still different:

ok      regexp  1.770s
ok      regexp/syntax   1.040s
--- FAIL: TestCgoExternalThreadSIGPROF (3.61s)
        crash_cgo_test.go:95: expected "OK\n", but got ""
FAIL
FAIL    runtime 135.428s
ok      runtime/debug   0.500s
exit status 255
FAIL    runtime/pprof   0.230s
ok      runtime/trace   65.243s
ok      sort    0.145s

@mikioh mikioh changed the title runtime: TestCgoExternalThreadSIGPROF and TestSignalExitStatus fail on netbsd7-amd64 runtime: TestCgoExternalThreadSIGPROF fails on netbsd7-amd64 Jan 22, 2016
@gopherbot
Copy link

CL https://golang.org/cl/18835 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/29491 mentions this issue.

gopherbot pushed a commit that referenced this issue Sep 21, 2016
…lly on dragonfly

This change reverts CL 18835 which is a workaroud for older DragonFly
BSD kernels, and fixes #14051, #14052 and #14067 in a more general way
the same as other platforms except NetBSD.

This change also bumps the minimum required version of DragonFly BSD
kernel to 4.4.4.

Fixes #16329.

Change-Id: I0b44b6afa675f5ed9523914226bd9ec4809ba5ae
Reviewed-on: https://go-review.googlesource.com/29491
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Sep 21, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants