CL 473415 allowed 5 more threads in TestWindowsStackMemory, to cover
sysmon and any new threads in future. However, during go1.22 dev cycle,
the test becomes flaky again, failing in windows-386 builder a couple of
times in CL 535975 and CL 536175 (and maybe others that haven't caught).
This CL increases the extra threads from 5 to 10, hopefully to make the
test stable again for windows-386. The theory is that Go process load a
bunch of DLLs, which may start their own threads. We could investigate
more deeply if the test still be flaky with 10 extra threads.
Fixes #58570
Change-Id: I255d0d31ed554859a5046fa76dfae1ba89a89aa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/536058
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
panic(err)
}
// assumes that this process creates 1 thread for each
- // thread locked goroutine plus extra 5 threads
+ // thread locked goroutine plus extra 10 threads
// like sysmon and others
- print((mem2 - mem1) / (threadCount + 5))
+ print((mem2 - mem1) / (threadCount + 10))
}
panic(err)
}
// assumes that this process creates 1 thread for each
- // thread locked goroutine plus extra 5 threads
+ // thread locked goroutine plus extra 10 threads
// like sysmon and others
- print((mem2 - mem1) / (threadCount + 5))
+ print((mem2 - mem1) / (threadCount + 10))
}