tree 3b127fb1220fbcd5a8285f75afaac2c71303dc33
parent cd671a1180441309e88c7113c86157e91888ded7
author Michael Anthony Knyszek <mknyszek@google.com> 1691096032 +0000
committer Than McIntosh <thanm@google.com> 1695646990 +0000

[release-branch.go1.21] runtime: always lock OS thread in debugcall

Right now debuggers like Delve rely on the new goroutine created to run
a debugcall function to run on the same thread it started on, up until
it hits itself with a SIGINT as part of the debugcall protocol.

That's all well and good, except debugCallWrap1 isn't particularly
careful about not growing the stack. For example, if the new goroutine
happens to have a stale preempt flag, then it's possible a stack growth
will cause a roundtrip into the scheduler, possibly causing the
goroutine to switch to another thread.

Previous attempts to just be more careful around debugCallWrap1 were
helpful, but insufficient. This change takes everything a step further
and always locks the debug call goroutine and the new goroutine it
creates to the OS thread.

For #61732.
Fixes #62509.

Change-Id: I038f3a4df30072833e27e6a5a1ec01806a32891f
Reviewed-on: https://go-review.googlesource.com/c/go/+/515637
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit d9a4b24a1775c4c5baa4ce3005cb5af61346198e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/526576