Issues #10240, #10541, #10941, #11023, #11027 and possibly others are
indicating memory corruption in the runtime. One of the easiest places
to both get corruption and detect it is in the allocator's free lists
since they appear throughout memory and follow strict invariants. This
commit adds a check when sweeping a span that its free list is sane
and, if not, it prints the corrupted free list and panics. Hopefully
this will help us collect more information on these failures.
Change-Id: I6d417bcaeedf654943a5e068bd76b58bb02d4a64
Reviewed-on: https://go-review.googlesource.com/10713
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
sweepgenset := false
// Mark any free objects in this span so we don't collect them.
+ sstart := uintptr(s.start << _PageShift)
for link := s.freelist; link.ptr() != nil; link = link.ptr().next {
+ if uintptr(link) < sstart || s.limit <= uintptr(link) {
+ // Free list is corrupted.
+ dumpFreeList(s)
+ throw("free list corrupted")
+ }
heapBitsForAddr(uintptr(link)).setMarkedNonAtomic()
}
}
return res
}
+
+func dumpFreeList(s *mspan) {
+ printlock()
+ print("runtime: free list of span ", s, ":\n")
+ sstart := uintptr(s.start << _PageShift)
+ link := s.freelist
+ for i := 0; i < int(s.npages*_PageSize/s.elemsize); i++ {
+ if i != 0 {
+ print(" -> ")
+ }
+ print(hex(link))
+ if link.ptr() == nil {
+ break
+ }
+ if uintptr(link) < sstart || s.limit <= uintptr(link) {
+ // Bad link. Stop walking before we crash.
+ print(" (BAD)")
+ break
+ }
+ link = link.ptr().next
+ }
+ print("\n")
+ printunlock()
+}