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

bcmills opened this issue Nov 8, 2019 · 2 comments


Copy link

@bcmills bcmills commented Nov 8, 2019

From plan9-386-0intro (, 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
            	/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
            	/tmp/workdir-gnot/go/src/runtime/mgcscavenge.go:211 +0x5b fp=0x11429fe8 sp=0x11429f7c pc=0x1d83b
            	/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
            	/tmp/workdir-gnot/go/src/runtime/mgc.go:216 +0x7e
            	/tmp/workdir-gnot/go/src/runtime/proc.go:166 +0x183
            	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1
FAIL	cmd/vet	34.760s

CC @aclements @mknyszek @0intro @fhs


This comment has been minimized.

Copy link

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


This comment has been minimized.

Copy link

@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
None yet
3 participants
You can’t perform that action at this time.