runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

bradfitz · 2016-10-06T19:06:08Z

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

The text was updated successfully, but these errors were encountered:

gopherbot · 2016-10-06T19:10:37Z

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

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>

rsc · 2016-10-21T00:42:53Z

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

bcmills · 2018-11-29T17:08:00Z

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 · 2018-11-29T17:08:47Z

Never mind, that one seems to be #28679.

laboger · 2018-11-30T15:58:33Z

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 · 2018-11-30T17:24:38Z

Thanks. Retitled this bug.

laboger · 2018-11-30T18:06:54Z

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 · 2018-11-30T18:10:54Z

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

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

quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 11, 2016

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

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

bcmills mentioned this issue May 21, 2020

runtime: move tests for runtime-gdb.py to a separate package and do not run them during all.bash #39204

Open

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

bradfitz commented Oct 6, 2016

gopherbot commented Oct 6, 2016

rsc commented Oct 21, 2016

bcmills commented Nov 29, 2018

bcmills commented Nov 29, 2018

laboger commented Nov 30, 2018

bradfitz commented Nov 30, 2018

laboger commented Nov 30, 2018

laboger commented Nov 30, 2018

runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

runtime: re-enable TestGdbPython and TestGdbBacktrace on linux/ppc64 (BE) if/when it gets cgo support #17366

Comments

bradfitz commented Oct 6, 2016

gopherbot commented Oct 6, 2016

rsc commented Oct 21, 2016

bcmills commented Nov 29, 2018

bcmills commented Nov 29, 2018

laboger commented Nov 30, 2018

bradfitz commented Nov 30, 2018

laboger commented Nov 30, 2018

laboger commented Nov 30, 2018