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

cmd/compile: CL 98415 seems to have broken some MIPS and PPC64 builders #24695

Closed
mvdan opened this issue Apr 5, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@mvdan
Copy link
Member

commented Apr 5, 2018

For example:

https://build.golang.org/log/e0e92d72d0a3ca60d2b158135c420739dc0b7308
https://build.golang.org/log/956610b6addc3783bca4ef6f9b4a784581a9693e
https://build.golang.org/log/1718e9a596ccee492fc8e5c7f7814122bd147024

The error is usually along the lines of:

--- FAIL: TestGdbBacktrace (2.26s)
	runtime-gdb_test.go:59: gdb version 7.9
	runtime-gdb_test.go:345: could not find '#0.*main\.eee' in backtrace
	runtime-gdb_test.go:346: gdb output:
		warning: File "/data/mips/go/src/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
		To enable execution of this file add
			add-auto-load-safe-path /data/mips/go/src/runtime/runtime-gdb.py
		line to your configuration file "/mips/proj/build-compiler/upstream-testing/go-lang/.gdbinit".
		To completely disable this security protection add
			set auto-load safe-path /
		line to your configuration file "/mips/proj/build-compiler/upstream-testing/go-lang/.gdbinit".
		For more information about this security protection see the
		"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
			info "(gdb)Auto-loading safe path"
		Breakpoint 1 at 0x67664: main.eee. (2 locations)
		
		Breakpoint 1, main.ddd (~r0=<optimized out>) at /tmp/go-build199996638/main.go:14
		14	func ddd() bool { return f() }
		#0  main.ddd (~r0=<optimized out>) at /tmp/go-build199996638/main.go:14
		#1  0x0006764c in main.ccc (~r0=<optimized out>) at /tmp/go-build199996638/main.go:11
		#2  0x00067600 in main.bbb (~r0=<optimized out>) at /tmp/go-build199996638/main.go:8
		#3  0x000675b4 in main.aaa (~r0=<optimized out>) at /tmp/go-build199996638/main.go:5
		#4  0x00067700 in main.main () at /tmp/go-build199996638/main.go:22
		
		Breakpoint 1, main.eee (~r0=<optimized out>) at /tmp/go-build199996638/main.go:17
		17	func eee() bool { return true }
FAIL
FAIL	runtime	146.377s

Note that these builders were already somewhat flakey, as can be seen on the build dashboard. But after that CL, they seem to almost always fail with this error.

/cc @dr2chase @randall77 @aclements @cherrymui

@mvdan mvdan added this to the Go1.11 milestone Apr 5, 2018

@mengzhuo

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

same as arm64

--- FAIL: TestGdbBacktrace (2.99s)
        runtime-gdb_test.go:59: gdb version 7.12
        runtime-gdb_test.go:345: could not find '#0.*main\.eee' in backtrace
        runtime-gdb_test.go:346: gdb output:
                warning: File "/root/godev/src/runtime/runtime-gdb.py" auto-loading has been declined by your `
auto-load safe-path' set to "$debugdir:$datadir/auto-load".
                To enable execution of this file add
                        add-auto-load-safe-path /root/godev/src/runtime/runtime-gdb.py
                line to your configuration file "/root/.gdbinit".
                To completely disable this security protection add
                        set auto-load safe-path /
                line to your configuration file "/root/.gdbinit".
                For more information about this security protection see the
                "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
                        info "(gdb)Auto-loading safe path"
                Breakpoint 1 at 0x56b10: main.eee. (2 locations)
                [New LWP 16406]
                [New LWP 16412]
                [New LWP 16413]
                [New LWP 16414]

                Thread 1 "a.exe" hit Breakpoint 1, main.ddd (~r0=<optimized out>) at /tmp/go-build289574404/mai
n.go:14
                14      func ddd() bool { return f() }
                #0  main.ddd (~r0=<optimized out>) at /tmp/go-build289574404/main.go:14
                #1  0x0000000000056ae8 in main.ccc (~r0=<optimized out>) at /tmp/go-build289574404/main.go:11
                #2  0x0000000000056aa8 in main.bbb (~r0=<optimized out>) at /tmp/go-build289574404/main.go:8
                #3  0x0000000000056a68 in main.aaa (~r0=<optimized out>) at /tmp/go-build289574404/main.go:5
                #4  0x0000000000056b88 in main.main () at /tmp/go-build289574404/main.go:22

                Thread 1 "a.exe" hit Breakpoint 1, main.eee (~r0=<optimized out>) at /tmp/go-build289574404/mai
n.go:17
                17      func eee() bool { return true }
FAIL
@dr2chase

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

I will look at this, I am happy to see a failure on arm64 since I actually have easy access to one of those.

@laboger

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

Not sure if this helps, but I tried this on a ppc64le system and here is what I see when I try to use gdb on the test program:

(gdb) break main.eee
Breakpoint 1 at 0x5b4a0: main.eee. (2 locations)
(gdb) run
Starting program: /home/boger/gotests/gdb/main 
Trying host libthread_db library: libthread_db.so.1.
Host libthread_db.so.1 resolved to: /lib/powerpc64le-linux-gnu/libthread_db.so.1.
td_ta_new failed: application not linked with libthread
thread_db_load_search returning 0
[New LWP 21710]
[New LWP 21711]
[New LWP 21712]
[New LWP 21713]
[New LWP 21714]

Thread 1 "main" hit Breakpoint 1, main.ddd (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:13
13	func ddd() bool { return f() }
(gdb) bt
#0  main.ddd (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:13
#1  0x000000000005b484 in main.ccc (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:10
#2  0x000000000005b444 in main.bbb (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:7
#3  0x000000000005b404 in main.aaa (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:4
#4  0x000000000005b524 in main.main () at /home/boger/gotests/gdb/main.go:21
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
	breakpoint already hit 1 time
1.1                         y     0x000000000005b4a0 in main.ddd at /home/boger/gotests/gdb/main.go:13
1.2                         y     0x000000000005b4f4 in main.eee at /home/boger/gotests/gdb/main.go:16
(gdb) 

Setting the breakpoint at main.eee also seems to be setting it at main.ddd in the latest.

I tried the same thing with a toolchain that's a bit older and it only set 1 breakpoint and the gdb traceback output looks right.

@gopherbot

This comment has been minimized.

Copy link

commented Apr 5, 2018

Change https://golang.org/cl/104955 mentions this issue: cmd/compile: ensure first instruction of function is stmt

@dr2chase

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

@laboger That helps -- it's the exact same failure as arm64. First instruction isn't marked as a statement, so gdb "isn't sure" if the 0x5b4a0 is in eee or the function containing the previous statement, which is ddd, so it sets breakpoints in both places.

@laboger

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

That fixes it.

@gopherbot gopherbot closed this in eda22a0 Apr 6, 2018

@mvdan

This comment has been minimized.

Copy link
Member Author

commented Apr 6, 2018

The PPC64 builders are already happy :) Thanks @dr2chase!

@mengzhuo

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2018

arm64 is happy too

Thanks @dr2chase

@golang golang locked and limited conversation to collaborators Apr 8, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.