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: "unexpected signal during runtime execution" during bgscavenge on plan9-386-0intro #35456

Open
bcmills opened this issue Nov 8, 2019 · 2 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 8, 2019

From plan9-386-0intro (https://build.golang.org/log/a94f5d80b1a5d38ecdf8b02bed7bfb305f569118), a cmd/vet test failure that appears to have nothing to do with cmd/vet:

--- FAIL: TestVet (1.94s)
    --- FAIL: TestVet/assign (0.43s)
        vet_test.go:162: error check failed: 
            assign.go:18: missing error "self-assignment of x to x"
            assign.go:20: missing error "self-assignment of s.x to s.x"
            assign.go:22: missing error "self-assignment of s.l.0. to s.l.0."
            Unmatched Errors:
            fatal error: unexpected signal during runtime execution
            [signal sys: trap: fault write code=0x0 addr=0x0 pc=0xa960]
            goroutine 4 [running]:
            runtime.throw(0x96394d, 0x2a)
            	/tmp/workdir-gnot/go/src/runtime/panic.go:1106 +0x63 fp=0x11429f44 sp=0x11429f30 pc=0x2e783
            runtime.sigpanic()
            	/tmp/workdir-gnot/go/src/runtime/os_plan9.go:79 +0x333 fp=0x11429f78 sp=0x11429f44 pc=0x2b033
            runtime.newobject(0x92d1a0, 0x0)
            	/tmp/workdir-gnot/go/src/runtime/malloc.go:1153 fp=0x11429f7c sp=0x11429f78 pc=0xa960
            runtime.bgscavenge(0x1143c000)
            	/tmp/workdir-gnot/go/src/runtime/mgcscavenge.go:211 +0x5b fp=0x11429fe8 sp=0x11429f7c pc=0x1d83b
            runtime.goexit()
            	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1 fp=0x11429fec sp=0x11429fe8 pc=0x573f1
            created by runtime.gcenable
            	/tmp/workdir-gnot/go/src/runtime/mgc.go:215 +0x6a
            goroutine 1 [chan receive, locked to thread]:
            runtime.gopark(0x96ee48, 0x1143c030, 0x1143170e, 0x2)
            	/tmp/workdir-gnot/go/src/runtime/proc.go:304 +0xd8
            runtime.chanrecv(0x1143c000, 0x0, 0x11400001, 0x1515a)
            	/tmp/workdir-gnot/go/src/runtime/chan.go:563 +0x275
            runtime.chanrecv1(0x1143c000, 0x0)
            	/tmp/workdir-gnot/go/src/runtime/chan.go:433 +0x1c
            runtime.gcenable()
            	/tmp/workdir-gnot/go/src/runtime/mgc.go:216 +0x7e
            runtime.main()
            	/tmp/workdir-gnot/go/src/runtime/proc.go:166 +0x183
            runtime.goexit()
            	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1
FAIL
FAIL	cmd/vet	34.760s

CC @aclements @mknyszek @0intro @fhs

@mknyszek

This comment has been minimized.

Copy link
Contributor

@mknyszek mknyszek commented Nov 8, 2019

This is very odd. It's failing very, very early in the runtime (right when the background scavenger is spinning up) trying to allocate a timer. And the problem seems to be that newobject has a nil type parameter? I'm not even sure how that can happen.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 8, 2019

The type parameter passed to newobject is 0x92d1a0. The 0x0 is the result parameter. The addr=0x0 printed at the start of the backtrace is meaningless, as this is not a fault signal, it is a trap signal. The trap signal does not set the address field (sigcode1) on Plan 9.

But that said I have no idea why the binary would get a trap signal. I don't know enough about Plan 9 to know what might cause that. If this happened only once I'm inclined to ignore it.

CC @0intro

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