Looks like a nil goroutine pointer. Crashes here:

	if gp.lockedm != 0 {

It should never be nil, given this code, previous to the above:

	if gp == nil {
		gp, inheritTime = findrunnable() // blocks until work is available
	}

Possibly findrunnable is returning nil when it shouldn't.
It finds work from a bunch of places. Most have obvious if gp != nil { return gp } guards, or would have crashed with a nil gp, but the one that returns the result of globrunqget doesn't. And it looks like it can return nil, if there's no global work.

I have a possible fix.

Nope, nevermind, that path doesn't actually return the nil gp...

Maybe somehow sched.runq and sched.runqsize are getting out of sync? Or there is a nil entryin sched.runq?

I'm not sure if this is the same issue as #37257, but I feel they are related.

@bcmills @randall77 Friendly ping for an update on this, as it's a release blocking issue for Go 1.15.

Possibly related:

2020-05-28T21:13:51-5a00adf/linux-mips64le-mengzhuo
2020-05-07T04:45:51-9e81578/linux-mips64le-mengzhuo

I don't see any other occurrences in the build logs.

2020-05-28T21:13:51-5a00adf/linux-mips64le-mengzhuo

runtime.throw(0x12066fa9e, 0x2a)
/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/panic.go:1116 +0x6c
runtime.sigpanic()
/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/signal_unix.go:704 +0x5f0
runtime.osyield(0x1e, 0x0, 0x0, 0x1, 0x4, 0x0, 0x3, 0x12004bff8, 0x120a01718, 0x100000002, ...)
/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/sys_linux_mips64x.s:495 +0x8

The faulting line is a RET instruction. The only possibility is the link register gets corrupted. I don't see how that could be possible...

Given that this only happened once and various people have determined that it appears impossible, this is almost certainly a flake. If it's not a flake, that's unfortunate, but there also doesn't appear to be anywhere near enough information to make further progress.