runtime: fpTraceback fails when trying to take a stack trace of a goroutine in a syscall

[mknyszek]

After https://go.dev/cl/567076 (for #65634) landed, the runtime began trying to take the frame-pointer-based stack trace of a goroutine in a syscall. Turns out, the runtime had never tried to this before, and it's totally broken.

The main issue is that traceStack tries to use gp.sched.bp but that's not even set when entering a syscall. Worse still, gp.sched in general could get clobbered by calling systemstack. It can then get updated again when switching back to the Go stack (since the syscall path wants to undo the clobbering).

For now, I'm just going to disable getting a stack trace for goroutines blocked in a syscall for the entirety of a generation. To resolve this, what we really need is a gp.syscallbp, akin to gp.syscallpc and gp.syscallsp. The latter two are already used by the regular stack unwinder if available, and they're actually stable, as opposed to gp.sched which gets mutated. Implementing that will be a bigger change, so I'm putting that on the backburner.

[nsrip-dd]

Aha! I wondered about this when looking into #66734.

Adding syscallbp makes sense to me. Perhaps we don't need to completely disable getting a stack trace, though? Could we fall back to the regular non-frame pointer stack trace method if the goroutine has a Gsyscall status? For example, changing this check to add an || readgstatus(gp)&_Gsyscall != 0 check to take the slow path.

[mknyszek]

Yeah, I just went ahead and implemented syscallbp. It wasn't hard.

[gopherbot]

Change https://go.dev/cl/580255 mentions this issue: runtime: track frame pointer while in syscall

[phuslu]

This PR altered the goid offset, potentially disrupting compatibility with several Go applications that depend on it. For those interested in the latest goid() support, I have updated my goid library here: https://github.com/phuslu/goid.