runtime: TestGdbBacktrace fails on netbsd/amd64

[mikioh]

git rev-parse HEAD: 0b6e5e3

all.bash on netbsd 7.0 (amd64) fails with the following:

--- FAIL: TestGdbBacktrace (1.25s)
        runtime-gdb_test.go:46: gdb version 7.7
        runtime-gdb_test.go:250: could not find '#0.*main\.eee' in backtrace
        runtime-gdb_test.go:251: gdb output:
                Breakpoint 1 at 0x4010d0: file /tmp/go-build516897324/main.go, line 17.

                Program received signal SIGTRAP, Trace/breakpoint trap.
                runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
                57              MOVL    AX, ret+32(FP)
                #0  runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
                #1  0x000000000041e442 in runtime.semasleep (ns=-1, ~r1=0) at /go/src/runtime/os_netbsd.go:124
                #2  0x00000000004092f3 in runtime.notesleep (n=0xc420026518) at /go/src/runtime/lock_sema.go:166
                #3  0x00000000004258b3 in runtime.stopm () at /go/src/runtime/proc.go:1576
                #4  0x00000000004260c5 in runtime.startlockedm (gp=0xc4200001a0) at /go/src/runtime/proc.go:1753
                #5  0x000000000042709a in runtime.schedule () at /go/src/runtime/proc.go:2115
                #6  0x0000000000427449 in runtime.park_m (gp=0xc420000820) at /go/src/runtime/proc.go:2165
                #7  0x000000000044407b in runtime.mcall () at /go/src/runtime/asm_amd64.s:240
                #8  0x000000c420018000 in ?? ()
                #9  0x0000000000000000 in ?? ()

                Program received signal SIGTRAP, Trace/breakpoint trap.
                runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
                57              MOVL    AX, ret+32(FP)
FAIL
FAIL    runtime 41.243s

[gopherbot]

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

[ianlancetaylor]

Moving to 1.8.

[aclements]

@mikioh, is this still happening? Assuming it is, can you check if gdb works at all on Go binaries on netbsd? It sort of looks like gdb is misinterpreting ptrace breaking on a system call as hitting a user breakpoint.

[mikioh]

is this still happening?

git rev-parse HEAD
524cd4855e11a26d07a7ca7ee45d3bee38c54425

go test -run=TestGdbBacktrace -flaky
--- FAIL: TestGdbBacktrace (0.45s)
        runtime-gdb_test.go:53: gdb version 7.7
        runtime-gdb_test.go:273: could not find '#0.*main\.eee' in backtrace
(snip)
                Program received signal SIGTRAP, Trace/breakpoint trap.
                runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
                57              MOVL    AX, ret+32(FP)
FAIL

looks like gdb is misinterpreting ptrace breaking on a system call

Looks like so.

cat test.go

package main

func main() {
        println(".")
}

(gdb) b main.main
(gdb) r
Starting program: /test 

Program received signal SIGTRAP, Trace/breakpoint trap.
runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
57              MOVL    AX, ret+32(FP)
(gdb) bt
#0  runtime.lwp_park () at /go/src/runtime/sys_netbsd_amd64.s:57
#1  0x000000000041fba7 in runtime.semasleep (ns=-1, ~r1=0)
    at /go/src/runtime/os_netbsd.go:138
#2  0x0000000000409cc9 in runtime.notesleep (n=0xc420026518)
    at /go/src/runtime/lock_sema.go:166
#3  0x000000000042718d in runtime.stopm () at /go/src/runtime/proc.go:1620
#4  0x00000000004279ae in runtime.startlockedm (gp=0xc4200001a0)
    at /go/src/runtime/proc.go:1797
#5  0x0000000000428918 in runtime.schedule () at /go/src/runtime/proc.go:2164
#6  0x0000000000428c6b in runtime.park_m (gp=0xc420000820)
    at /go/src/runtime/proc.go:2214
#7  0x00000000004436bb in runtime.mcall () at /go/src/runtime/asm_amd64.s:256
#8  0x000000c420018000 in ?? ()
#9  0x0000000000000000 in ?? ()

[aclements]

In that case, this is a gdb or, more likely, NetBSD bug and there's probably nothing Go can do about it. Would you mind reporting it to NetBSD? (Or I could, but I have zero experience with NetBSD.)