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

os/signal: test fails with trace trap on netbsd7-amd64 #14051

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

os/signal: test fails with trace trap on netbsd7-amd64 #14051

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      os      0.822s
ok      os/exec 1.065s
SIGTRAP: trace trap
PC=0x458e3e m=5

goroutine 0 [idle]:
runtime.morestack()
        /home/rillig/git/go/src/runtime/asm_amd64.s:338 +0x2e

goroutine 11 [syscall]:
syscall.Syscall(0x25, 0x1de9, 0x1e, 0x0, 0x0, 0x0, 0x0)
        /home/rillig/git/go/src/syscall/asm_netbsd_amd64.s:21 +0x5 fp=0xc82001a740 sp=0xc82001a738
syscall.Kill(0x1de9, 0x1e, 0x0, 0x0)
        /home/rillig/git/go/src/syscall/zsyscall_netbsd_amd64.go:657 +0x4b fp=0xc82001a780 sp=0xc82001a740
os/signal.TestStress.func2(0xc820064660, 0xc8200646c0)
        /home/rillig/git/go/src/os/signal/signal_test.go:96 +0x8d fp=0xc82001a7b0 sp=0xc82001a780
runtime.goexit()
        /home/rillig/git/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc82001a7b8 sp=0xc82001a7b0
created by os/signal.TestStress
        /home/rillig/git/go/src/os/signal/signal_test.go:101 +0x10b

goroutine 1 [chan receive]:
testing.RunTests(0x5e08b0, 0x672cc0, 0x7, 0x7, 0x1)
        /home/rillig/git/go/src/testing/testing.go:583 +0x8d2
testing.(*M).Run(0xc820035ef8, 0x24)
        /home/rillig/git/go/src/testing/testing.go:515 +0x81
main.main()
        os/signal/_test/_testmain.go:68 +0x117

goroutine 5 [syscall]:
os/signal.signal_recv(0x7f7ff7f70078)
        /home/rillig/git/go/src/runtime/sigqueue.go:116 +0x132
os/signal.loop()
        /home/rillig/git/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
        /home/rillig/git/go/src/os/signal/signal_unix.go:28 +0x37

goroutine 9 [sleep]:
time.Sleep(0x5f5e100)
        /home/rillig/git/go/src/runtime/time.go:59 +0xf9
os/signal.TestStress(0xc8200121b0)
        /home/rillig/git/go/src/os/signal/signal_test.go:102 +0x119
testing.tRunner(0xc8200121b0, 0x672cd8)
        /home/rillig/git/go/src/testing/testing.go:473 +0x98
created by testing.RunTests
        /home/rillig/git/go/src/testing/testing.go:582 +0x892

goroutine 8 [select, locked to thread]:
runtime.gopark(0x5e0d00, 0xc820021728, 0x59c2a0, 0x6, 0x18, 0x2)
        /home/rillig/git/go/src/runtime/proc.go:262 +0x163
runtime.selectgoImpl(0xc820021728, 0x0, 0x18)
        /home/rillig/git/go/src/runtime/select.go:392 +0xa67
runtime.selectgo(0xc820021728)
        /home/rillig/git/go/src/runtime/select.go:215 +0x12
runtime.ensureSigM.func1()
        /home/rillig/git/go/src/runtime/signal1_unix.go:279 +0x340
runtime.goexit()
        /home/rillig/git/go/src/runtime/asm_amd64.s:1998 +0x1

goroutine 10 [runnable]:
os/signal.TestStress.func1(0xc820064660, 0xc8200646c0)
        /home/rillig/git/go/src/os/signal/signal_test.go:81 +0x235
created by os/signal.TestStress
        /home/rillig/git/go/src/os/signal/signal_test.go:88 +0xdf

rax    0xc82001a738
rbx    0xc820024c00
rcx    0xc820001680
rdx    0x0
rdi    0x1de9
rsi    0xc820001680
rbp    0x1
rsp    0xc82001a6e8
r8     0x0
r9     0x0
r10    0x0
r11    0x246
r12    0x6
r13    0x5dfcb4
r14    0x3
r15    0x8
rip    0x458e3e
rflags 0x246
cs     0x47
fs     0x0
gs     0x0
FAIL    os/signal       0.061s
ok      os/user 0.015s
ok      path    0.017s
@ianlancetaylor
Copy link
Contributor

The fix (now) applied on tip is somewhat different than CL 18776. I can't recreate this problem on tip. If you can recreate it on tip, please run it with GOTRACEBACK=2. Also, what is your GOMAXPROCS setting?

@rillig
Copy link
Contributor Author

rillig commented Jan 22, 2016

I tested it with 1b6d55a. The trace trap is gone, its place is now taken by fatal error: exitsyscall: syscall frame is no longer valid

14051-output-syscall-frame.txt

Should that go into a new ticket or will we continue this one?

@mikioh
Copy link
Contributor

mikioh commented Jan 22, 2016

@rillig,

See #14067 and try https://go-review.googlesource.com/#/c/18835/. I think the series of clarification on signal behavior for Go 1.6 are all set.

@rillig
Copy link
Contributor Author

rillig commented Jan 22, 2016

Wow. All the runtime/* tests run through with the abovementioned change. That’s impressive. So I think this issue can be closed.

@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

5 participants