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: TestGdbBacktrace fails on netbsd/amd64 #15603

Closed
mikioh opened this issue May 8, 2016 · 5 comments
Closed

runtime: TestGdbBacktrace fails on netbsd/amd64 #15603

mikioh opened this issue May 8, 2016 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@mikioh
Copy link
Contributor

mikioh commented May 8, 2016

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
@mikioh mikioh added this to the Go1.7Maybe milestone May 8, 2016
@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue May 27, 2016
Also adds missing copyright notice.

Updates #15603.

Change-Id: Icf4bb45ba5edec891491fe5f0039a8a25125d168
Reviewed-on: https://go-review.googlesource.com/23501
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@mikioh mikioh added the Testing An issue that has been verified to require only test changes, not just a test failure. label May 30, 2016
@ianlancetaylor
Copy link
Contributor

Moving to 1.8.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.8, Go1.7Maybe Jun 28, 2016
@quentinmit quentinmit added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 29, 2016
@aclements
Copy link
Member

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

@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 11, 2016
@mikioh
Copy link
Contributor Author

mikioh commented Nov 13, 2016

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
Copy link
Member

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.)

@golang golang locked and limited conversation to collaborators Nov 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Development

No branches or pull requests

6 participants