Skip to content
New issue

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

runtime, cmd/compile: possible bad pointers with map[struct{}]struct{} #21508

Closed
josharian opened this issue Aug 17, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@josharian
Copy link
Contributor

commented Aug 17, 2017

Many places in the hashmap implementation, we calculate key/val pointers that might point at the end of the bucket if both key and value have zero size.

Given how rare this is, I'd hate to complicate the map routines with checks everywhere. One possible fix is to have special mapfast routines just for maps with zero-sized keys and values, which would then generally be dead-code eliminated.

Other ideas?

@randall77

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2017

Maybe it'd suffice to set maptype.valuesize to 1 for such maps.

@martisch

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

special map fast routines sounds good. Since this should be very rare they will not usually end up in the binary and they dont complicate existing code.

I was also looking into making other special zero sized elem methods for other make methods since they are rare and we can slim down the common code paths:

  • growslice
  • makechan (for zero sized elems and queue)
    In both situations we have simpler overflow tests too since there are less multiplications involved.
    But i am currently working to slim down and get the current methods work with overflow correctly before splitting or duplicating them.

So specializing map functions sounds good.

@randall77

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2017

So I totally forgot that we pushed the overflow pointer to the end of the bucket exactly to solve this sort of problem, and the one in #21459 . So even if key/value pointers are incremented a final time, or keys or values are zero-sized, we still can't get a beyond-the-object pointer.

@randall77 randall77 closed this Aug 18, 2017

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Aug 18, 2017

Oh right. Yay! For future reference, the original bug was #9384 and fix was CL 1869.

@golang golang locked and limited conversation to collaborators Aug 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.