In TestMorestack, on macOS, for some reason it got most of the
samples in synchronization (e.g. pthread_cond_signal and
pthread_cond_wait) and sometimes in other "syscalls" (usleep,
nanotime1), and very few samples in stack copying, sometimes 0,
which causes the test to fail. Maybe synchronization is slower on
macOS? (It doesn't seem so to me.) Or it is the OS's accounting
problem, where it is more likely to trigger a profiling signal
at a syscall (or certain kinds of syscalls)?
As the test is really about whether it can connect stack copying
with the function that grows the stack, this CL makes it spend
more time in copying stack than synchronization. Now it's getting
~100 samples for stack copying on a 5 second interval on my
machine, and the test passes reliably.
Fixes #44418.
Change-Id: I3a462c8c39766f2d67d697598f8641bbe64f16ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/307730
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>