runtime: "unexpected signal during runtime execution" during bgscavenge on plan9-386-0intro

[bcmills]

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

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