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: TestAbort failing on Plan 9 #26265

Closed
0intro opened this issue Jul 7, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@0intro
Copy link
Member

commented Jul 7, 2018

Since CL 122515, TestAbort is failing on Plan 9.

--- FAIL: TestAbort (0.06s)
    crash_test.go:95: testprog Abort exit status: exit status: 'testprog.exe 5275: sys: breakpoint pc=0x00046fd1'
    crash_test.go:657: output does not contain "SIGTRAP":
        sys: breakpoint pc=0x00046fd1
        PC=0x46fd1
        
        goroutine 1 [running]:
        runtime.abort()
        	/tmp/workdir/go/src/runtime/asm_386.s:866 +0x1 fp=0x10426f54 sp=0x10426f50 pc=0x46fd1
        main.Abort()
        	/tmp/workdir/go/src/runtime/testdata/testprog/abort.go:21 +0x33 fp=0x10426f60 sp=0x10426f54 pc=0x93f83
        main.main()
        	/tmp/workdir/go/src/runtime/testdata/testprog/main.go:34 +0x14d fp=0x10426fd0 sp=0x10426f60 pc=0x96d4d
        runtime.main()
        	/tmp/workdir/go/src/runtime/proc.go:201 +0x202 fp=0x10426ff0 sp=0x10426fd0 pc=0x26442
        runtime.goexit()
        	/tmp/workdir/go/src/runtime/asm_386.s:1324 +0x1 fp=0x10426ff4 sp=0x10426ff0 pc=0x473b1
        
        goroutine 2 [runnable]:
        runtime.forcegchelper()
        	/tmp/workdir/go/src/runtime/proc.go:243 fp=0x10427ff0 sp=0x10427fec pc=0x26600
        runtime.goexit()
        	/tmp/workdir/go/src/runtime/asm_386.s:1324 +0x1 fp=0x10427ff4 sp=0x10427ff0 pc=0x473b1
        created by runtime.init.3
        	/tmp/workdir/go/src/runtime/proc.go:240 +0x2a
        
        goroutine 3 [GC sweep wait]:
        runtime.gopark(0xc2560, 0x1598d0, 0x1140c, 0x1)
        	/tmp/workdir/go/src/runtime/proc.go:302 +0xe2 fp=0x10428fc4 sp=0x10428fb0 pc=0x26822
        runtime.goparkunlock(0x1598d0, 0xd140c, 0x1)
        	/tmp/workdir/go/src/runtime/proc.go:308 +0x44 fp=0x10428fd8 sp=0x10428fc4 pc=0x268b4
        runtime.bgsweep(0x1043e000)
        	/tmp/workdir/go/src/runtime/mgcsweep.go:52 +0x80 fp=0x10428fe8 sp=0x10428fd8 pc=0x1a150
        runtime.goexit()
        	/tmp/workdir/go/src/runtime/asm_386.s:1324 +0x1 fp=0x10428fec sp=0x10428fe8 pc=0x473b1
        created by runtime.gcenable
        	/tmp/workdir/go/src/runtime/mgc.go:216 +0x48
        
        goroutine 4 [runnable]:
        runtime.runfinq()
        	/tmp/workdir/go/src/runtime/mfinal.go:161 fp=0x10429ff0 sp=0x10429fec pc=0x11620
        runtime.goexit()
        	/tmp/workdir/go/src/runtime/asm_386.s:1324 +0x1 fp=0x10429ff4 sp=0x10429ff0 pc=0x473b1
        created by runtime.createfing
        	/tmp/workdir/go/src/runtime/mfinal.go:156 +0x5f
        
        ax    0x0
        bx    0x1043c000
        cx    0x0
        dx    0xc22d8
        di    0x0
        si    0xf7
        bp    0x1c
        sp    0x10426f50
        pc    0x46fd1
        flags 0x246
        cs    0x23
        fs    0x1b
        gs    0x1b
FAIL
FAIL	runtime	46.386s

See https://build.golang.org/log/d72b3d5887ea8a9a09a448428022b8b85fd26757

@0intro 0intro added the OS-Plan9 label Jul 7, 2018

@0intro 0intro added this to the Go1.11 milestone Jul 7, 2018

@0intro 0intro self-assigned this Jul 7, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jul 7, 2018

Change https://golang.org/cl/122464 mentions this issue: runtime: fix TestAbort on Plan 9

@gopherbot gopherbot closed this in b001ffb Jul 8, 2018

@millerresearch

This comment has been minimized.

Copy link

commented Jul 8, 2018

This fix appears to work only on plan9_386, but not on plan9_arm. runtime.abort on 386 is an INT $3 instruction (breakpoint), while on ARM it's "MOVW $0, R0; MOVW (R0),R1" which causes a read fault.

Note that the test failure isn't Plan 9 specific -- it's failing on some linux_arm builders too.

@0intro

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2018

Indeed. Maybe we can add the "sys: trap: fault read" string in the switch?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2018

This may have been fixed by the recently committed https://golang.org/cl/122580.

@0intro

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2018

This change does indeed fix the issue. Thanks.

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