These tests run the runtime, reflect, and sync package tests with the
two maymorestack hooks we have.
These tests only run on the longtest builders (or with
GO_TEST_SHORT=false) because we're running the runtime test two
additional times and the mayMoreStackMove hook makes it about twice as
slow (~230 seconds).
To run just these tests by hand, do
GO_TEST_SHORT=false go tool dist test -run mayMoreStack
This detected #49354, which was found as a flake on the dashboard, but
was reliably reproducible with these tests; and #49395.
Run-TryBot: Austin Clements <firstname.lastname@example.org>
TryBot-Result: Gopher Robot <email@example.com>
Auto-Submit: Austin Clements <firstname.lastname@example.org>
Reviewed-by: Cherry Mui <email@example.com>
It's currently possible for a poorly timed stack split in
runtime.(*consistentHeapStats).releaseto lead to a fatal "bad sequence number". The exact steps are:
This is effectively a "double acquire", which causes acquire to panic with "bad sequence number".
I found this using the maymorestack tests added in CL 361212. @mknyszek already has a fix.
The text was updated successfully, but these errors were encountered: