We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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?
to your account
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.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.
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
No branches or pull requests