Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trace
wbufSpans
2022-05-08T17:28:26-1b86ef4/linux-amd64-staticlockranking:
37363 ====== 0 : trace 28 0x8485a0 1 : wbufSpans 39 0x840770 fatal error: lock ordering problem
(attn @golang/runtime; see previously #41021)
The text was updated successfully, but these errors were encountered:
If I understand the log correctly, this would mean that lockrank.go would not allow write barriers when an M is holding trace.lock. The call to gcWriteBarrierCX comes from https://github.com/golang/go/blob/1b86ef47de/src/runtime/trace.go#L410, setting trace.strings = nil. But that line also exists in go1.18.1, still within the section that holds trace.lock https://github.com/golang/go/blob/go1.18.1/src/runtime/trace.go#L368.
trace.lock
gcWriteBarrierCX
trace.strings = nil
Another "missing, but valid, edge on the wbufSpans lock"?
I don't see lockRankTrace in the list for lockRankMHeap https://github.com/golang/go/blob/1b86ef47de/src/runtime/lockrank.go#L244 , but I also don't see anywhere in runtime.StopTrace that allocates .. only write barriers.
lockRankTrace
lockRankMHeap
runtime.StopTrace
Sorry, something went wrong.
@rhysh Yeah, this just looks like a missing edge to me. The write barrier path can acquire the mheap lock in order to allocate a new write barrier buffer.
Change https://go.dev/cl/405476 mentions this issue: runtime: add lock partial order edge for trace and wbufSpans and mheap
runtime: add lock partial order edge for trace and wbufSpans and mheap
482669d
No branches or pull requests
2022-05-08T17:28:26-1b86ef4/linux-amd64-staticlockranking:
(attn @golang/runtime; see previously #41021)
The text was updated successfully, but these errors were encountered: