When running a goroutine, mp.curg points to the user goroutine, and mp.curg.m points back to mp.

The transition points are:

• execute which sets mp.curg and then mp.curg.m.
• dropg which does the opposite, clearing mp.curg.m and then mp.curg.

Thus, there are two small critical sections that may have mp.curg != nil but mp.curg.m == nil.

When handling a SIGPROF during cgo execution, we pass mp.curg to gentraceback, specifically with the condition mp.ncgo > 0 && mp.curg != nil && mp.curg.syscallpc != 0 && mp.curg.syscallsp != 0.

gentraceback then assumes gp.m != nil for _TraceJumpStack, and would crash on a curg in one of these critical sections.

This is reachable during cgocallback, which calls exitsyscall without decrementing ncgo [1]. If no Ps are available, exitsyscall calls exitsyscall0, which calls both dropg and (eventually) execute. Thus if a SIGPROF lands in the critical sections, gentraceback will crash [2].

I have managed to reproduce this locally with a program that:

1. Uses pprof profiling.
2. Makes tons of cgo calls with Go callbacks from more goroutines that GOMAXPROCS, so that some will be starved of of a P in exitsyscall.
3. Adjusted sysmon to retake Ps from cgo calls (aka syscalls) more aggressively than the default 20us/10ms to make the starved case more frequent.

(3) makes this difficult for me to make a regression test, but I may be able to eliminate this and just get a lower failure rate.

[1] Standard cgocall decrements ncgo prior to exitsyscall, though reentrant calls would also make this condition reachable as ncgo will still be > 0.
[2] Interestingly, this also meets the qualifications for cgoSigtramp to call the C traceback function, which will actually end up doing a traceback of Go code. This isn't a bug, just an odd edge case.

cc @cherrymui @aclements @mknyszek