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: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

Open
bradfitz opened this Issue Oct 6, 2016 · 8 comments

Comments

Projects
None yet
6 participants
@bradfitz
Member

bradfitz commented Oct 6, 2016

--- FAIL: TestGdbPython (0.30s)
    runtime-gdb_test.go:50: gdb version 7.7
    runtime-gdb_test.go:152: package testing source file: /tmp/workdir/go/src/testing/testing.go
    runtime-gdb_test.go:153: failed to load Go runtime support: "/tmp/go-build613978241/a.exe": not in executable format: File format not recognized
        "/tmp/go-build613978241/a.exe": not in executable format: File format not recognized
        No auto-load scripts.
        No symbol table is loaded.  Use the "file" command.
        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
        No executable file specified.
        Use the "file" or "exec-file" command.
        BEGIN info goroutines
        Undefined info command: "goroutines".  Try "help info".
        END
        No stack.
        BEGIN print mapvar
        No symbol table is loaded.  Use the "file" command.
        END
        BEGIN print strvar
        No symbol table is loaded.  Use the "file" command.
        END
        No stack.
        BEGIN goroutine 2 bt
        Undefined command: "goroutine".  Try "help".
        END
--- FAIL: TestGdbBacktrace (0.15s)
    runtime-gdb_test.go:50: gdb version 7.7
    runtime-gdb_test.go:264: could not find '#0.*main\.eee' in backtrace
    runtime-gdb_test.go:265: gdb output:
        "/tmp/go-build806889452/a.exe": not in executable format: File format not recognized
        No symbol table is loaded.  Use the "file" command.
        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
        No executable file specified.
        Use the "file" or "exec-file" command.
        No stack.
        The program is not being run.
FAIL
FAIL    runtime 14.687s

I propose we skip these tests there for now so we can see what else is failing. (These tests already skip if gdb is absent anyway)

/cc @dr2chase

@bradfitz bradfitz added this to the Go1.8Maybe milestone Oct 6, 2016

@gopherbot

This comment has been minimized.

gopherbot commented Oct 6, 2016

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

gopherbot pushed a commit that referenced this issue Oct 6, 2016

runtime: skip gdb tests on linux/ppc64 for now
Updates #17366

Change-Id: Ia4bd3c74c48b85f186586184a7c2b66d3b80fc9c
Reviewed-on: https://go-review.googlesource.com/30596
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

@quentinmit quentinmit added the NeedsFix label Oct 11, 2016

@rsc

This comment has been minimized.

Contributor

rsc commented Oct 21, 2016

I believe ppc64 (big endian) is essentially unsupported.
Unless the problem also manifests on ppc64le, I think this is unplanned work.

@rsc rsc modified the milestones: Unplanned, Go1.8Maybe Oct 21, 2016

@bcmills

This comment has been minimized.

Member

bcmills commented Nov 29, 2018

Unless the problem also manifests on ppc64le, I think this is unplanned work.

Here's a flake observed on linux/ppc64le. Same test, but a different failure mode.
https://build.golang.org/log/0c0a8553ebc6c605bd20ed1fd8ec44b81e2575e1.

##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick
--- FAIL: TestGdbPython (0.57s)
    runtime-gdb_test.go:66: gdb version 7.7
    runtime-gdb_test.go:213: gdb output: Loading Go Runtime support.
        Loaded  Script                                                                 
        Yes     /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/runtime-gdb.py      
        Breakpoint 1 at 0x9333c: file /tmp/go-build160953289/main.go, line 15.
        hi
        
        Breakpoint 1, main.main () at /tmp/go-build160953289/main.go:17
        17		gslice = slicevar
        BEGIN info goroutines
        * 1 running  syscall.Syscall
          2 runnable runtime.forcegchelper
          17 waiting  runtime.gopark
          18 runnable runtime.runfinq
        END
        BEGIN print mapvar
        $1 = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"}
        END
        BEGIN print strvar
        $2 = "abc"
        END
        BEGIN info locals
        mapvar = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"}
        strvar = "abc"
        slicevar =  []string
        END
        BEGIN goroutine 1 bt
        #0  main.main () at /tmp/go-build160953289/main.go:17
        END
        BEGIN goroutine 2 bt
        #0  runtime.forcegchelper () at /tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/proc.go:242
        #1  0x000000000009333c in fmt.Println (a=..., n=<optimized out>, err=...) at /tmp/workdir-host-linux-ppc64le-osu/go/src/fmt/print.go:275
        #2  main.main () at /tmp/go-build160953289/main.go:14
        Traceback (most recent call last):
          File "/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/runtime-gdb.py", line 536, in invoke
            gdb.parse_and_eval('$sp = $save_sp')
        gdb.error: Attempt to assign to an unmodifiable value.
        Error occurred in Python command: Attempt to assign to an unmodifiable value.
        END
        Breakpoint 2 at 0x93370: file /tmp/go-build160953289/main.go, line 18.
        runtime: newstack sp=0xc000032fc0 stack=[0xc000064000, 0xc000065000]
        	morebuf={pc:0x9333c sp:0xc000032fc0 lr:0x0}
        	sched={pc:0x39424 sp:0xc000032fc0 lr:0x9333c ctxt:0x0}
        runtime: gp=0xc000000180, goid=1, gp->status=0x2
         runtime: split stack overflow: 0xc000032fc0 < 0xc000064000
        fatal error: runtime: split stack overflow
        
        runtime stack:
        runtime.throw(0xd4daa, 0x1d)
        	/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/panic.go:608 +0x5c
        runtime.newstack()
        	/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/stack.go:995 +0x7a4
        runtime.morestack()
        	/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/asm_ppc64x.s:339 +0x60
        
        goroutine 1 [running]:
        runtime.forcegchelper()
        	/tmp/workdir-host-linux-ppc64le-osu/go/src/runtime/proc.go:242 +0x14 fp=0xc000032fc0 sp=0xc000032fc0 pc=0x39424
        runtime: unexpected return pc for main.main called from 0x0
        stack: frame={sp:0xc000032fc0, fp:0xc000033080} stack=[0xc000064000,0xc000065000)
        
        fmt.Println(...)
        	/tmp/workdir-host-linux-ppc64le-osu/go/src/fmt/print.go:275
        main.main()
        	/tmp/go-build160953289/main.go:14 +0x1ec fp=0xc000033080 sp=0xc000032fc0 pc=0x9333c
        [Inferior 1 (process 12962) exited with code 02]
        BEGIN goroutine 1 bt at the end
        No such goroutine:  1
        END
        
    runtime-gdb_test.go:286: goroutine 1 bt at the end failed: No such goroutine:  1
FAIL
FAIL	runtime	34.375s
@bcmills

This comment has been minimized.

Member

bcmills commented Nov 29, 2018

Never mind, that one seems to be #28679.

@laboger

This comment has been minimized.

Contributor

laboger commented Nov 30, 2018

linux/ppc64 does not support cgo. The reason this test fails on linux/ppc64 is that it tries to build a program to be debugged with gdb, but the program uses cgo so cannot be built. The failure has nothing to do with gdb.

If you use a program that can be built with linux/ppc64, gdb and the gdb python scripts should work on linux/ppc64 as well as linux/ppc64le. Everything that gdb looks at (the stack, register usage, threads and goroutines) should be the same between linux/ppc64 and linux/ppc64le.

I tried gdb on a simple hello.go test and things worked fine:

Breakpoint 1 at 0x94680: file /home/boger/gotests/hello.go, line 8.
(gdb) run
Starting program: /home/boger/gotests/hello 
[New LWP 5583]
[New LWP 5584]
[New LWP 5585]
[New LWP 5586]
[New LWP 5587]

Thread 1 "hello" hit Breakpoint 1, fmt.Printf (format=..., a=..., n=<optimized out>, err=...)
    at /home/boger/golang/go/src/fmt/print.go:208
208		return Fprintf(os.Stdout, format, a...)
(gdb) info goroutines
* 1 running  runtime.systemstack_switch
  2 waiting  runtime.gopark
  17 waiting  runtime.gopark
  18 waiting  runtime.gopark
(gdb) goroutine 1 bt
#0  fmt.Printf (format=..., a=..., n=<optimized out>, err=...) at /home/boger/golang/go/src/fmt/print.go:208
#1  main.main () at /home/boger/gotests/hello.go:8
(gdb) goroutine 2 bt
#0  runtime.gopark (unlockf=<optimized out>, lock=0x173b50 <runtime.forcegc>, reason=16 '\020', traceEv=20 '\024', 
    traceskip=1) at /home/boger/golang/go/src/runtime/proc.go:302
#1  0x00000000000392d4 in runtime.goparkunlock (reason=<optimized out>, traceEv=<optimized out>, 
    traceskip=<optimized out>, lock=<optimized out>) at /home/boger/golang/go/src/runtime/proc.go:307
#2  runtime.forcegchelper () at /home/boger/golang/go/src/runtime/proc.go:250
#3  0x0000000000060bc4 in runtime.goexit () at /home/boger/golang/go/src/runtime/asm_ppc64x.s:857
Backtrace stopped: frame did not save the PC

@bradfitz bradfitz changed the title from runtime: TestGdbPython and TestGdbBacktrace fail on linux/ppc64 (BE) to runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support Nov 30, 2018

@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 30, 2018

Thanks. Retitled this bug.

@laboger

This comment has been minimized.

Contributor

laboger commented Nov 30, 2018

Actually I just got on a system where gdb was at a high enough level and removed the check to skip tests on linux/ppc64, and found that those tests that need cgo are skipped if cgo is not enabled. And those that don't need it pass. I can submit the change if you want it now.

@laboger

This comment has been minimized.

Contributor

laboger commented Nov 30, 2018

Oh, the builder has to have at least gdb 7.7 or the tests in question are skipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment