You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Earlier on in the review process the return value was indeed an int, but this was used as a shift in multiple places, so I changed the whole pallocBits API to return uints.
Luckily these are just sanity checks, but if there is a bug in the page allocator, it could lead to bad pointers being returned (and possibly memory corruption).
Uploaded a fix. We may want to backport this. Like I said before, if there's a bug in the page allocator that would cause these sanity checks to fail, it would manifest as memory corruption as opposed to the immediate failure it was supposed to be.
CC @bcmills who has been tracking a bunch of the memory corruption issues.
CC @randall77@cherrymui who have been looking into some of the memory corruption issues.
I wonder whether this should become a vet check. I think with vet, we can at least find very simple instance (eg: unsigned number < 0); prove is able to find similar always-true or always-false conditions in more complicated situations which vet wouldn't be able to; but prove of course cannot emit a compile-time error.
Maybe this should go into what @dr2chase was doing, that is a log of "important information" written by the compiler during compilation.
While investigating the optimizations performed by my prove CL 196679, I found out these two instances of what looks like dead code:
go/src/runtime/mpagealloc.go
Lines 726 to 734 in d99fe1f
go/src/runtime/mpagealloc.go
Lines 768 to 773 in d99fe1f
That branch is never taken because
pallocBits.find()
return an unsigned number:go/src/runtime/mpallocbits.go
Lines 197 to 206 in d99fe1f
Given the documentation, it looks like the failure is reported as
^uint(0)
so the above checks are probably wrong./cc @aclements @mknyszek
The text was updated successfully, but these errors were encountered: