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

[rillig]

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]

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]

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]

@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]

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

[gopherbot]

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

[gopherbot]

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