It's currently possible for a poorly timed stack split in runtime.(*consistentHeapStats).release to lead to a fatal "bad sequence number". The exact steps are:
mcache.refill calls consistentHeapStats.acquire
mcache.refill updates heap stats
mcache.refill calls consistentHeapStats.release
The prologue of consistentHeapStats.release performs a stack split before the release actually happens
This enters the stack allocator, which eventually calls consistentHeapStats.acquire
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:
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
Updates #48297.
This detected #49354, which was found as a flake on the dashboard, but
was reliably reproducible with these tests; and #49395.
Change-Id: If785a8b8d6e1b9ad4d2ae67493b54055ab6cbc85
Reviewed-on: https://go-review.googlesource.com/c/go/+/361212
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
It's currently possible for a poorly timed stack split in
runtime.(*consistentHeapStats).release
to 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: