Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Eyeballing the hex dump, it looks to me that the bad pointer is found in a g struct, in g._defer field.
The stack bounds matches the stack of goroutine 67, as well as g.sched.pc and g.sched.sp.
What's interesting is that the bad pointer 0xc0005313e0 is also within the stack bound, in particular, within this frame
Presumably it is a stack-allocated defer. I don't know why spanOf does not find the span of the stack, returns a different span instead...
This also looks like the g._defer field in a g. The stack bounds match goroutine 1.
What's more interesting is that findObject and badPointer were complaining about pointer 0xc000346ef8, but in the object dump the field is actually containing 0xc00034a688, a different value.
I think g._defer can only change synchronously, right? But the goroutine is not running...
Also, the span's address range, [0xc000346000, 0xc000355e00], overlaps with the stack bounds [0xc00033c000, 0xc00034c000], assuming my interpretation of the hex dump is right. How could this be possible?
@aclements any idea how g._defer could change this way, or how span tracking could go weirdly?
Another one today https://build.golang.org/log/a810adac990353a9918a366fc13538c03649d206
@mengzhuo Only the scavenger (mgcscavenge.go) operates in terms of physical pages, the runtime page size is always 8 KiB on all platforms, so 8 KiB alignment is exactly what we want.
It could be related to the page allocator, but the physical page size here doesn't matter, I don't think.