-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: use of large map key causes crash #3573
Labels
Milestone
Comments
Fails on Mac too. Labels changed: added priority-asap, removed priority-triage. Owner changed to @dvyukov. Status changed to Accepted. |
It's a straighforward but very serious bug. The hashmap code uses a uint8 to store the size of a data element. That means that the hashmap code fails if the total of the key size plus the data size, with appropriate rounding, is >= 256. That was fine before Go 1, but it failed once we started to permit struct and array values to be used as hash keys. But strangely there is already an assertion to check for this type of error in hash_init: assert (h->datasize == datasize); Ah, but it doesn't work because the caller uses h->valoff, which is itself a uint8 field. Here is a possible fix but I'm not sure it's ideal or complete: http://golang.org/cl/6137051 Owner changed to ---. |
This issue was closed by revision bf18d57. Status changed to Fixed. |
This appears not to be fixed at tip. $ go tool 6g -V 6g version weekly.2012-03-27 +d8e47164f8dd The following code demonstrates a variety of errors: package main import "fmt" const id = "scaf" // or var id = "scaf" or other values - see comments below type sf struct { id string i int } type sp struct { a, b sf } func main() { seen := map[sp]struct{}{} for i := 0; i < 500; i++ { fmt.Println(i) a := sf{id, i} aa := sp{a, a} seen[aa] = struct{}{} } } The results depend on the value of and 'type' of id: if it's const "" then the result is always a `throw: hashmap assert`, if it's a var "" then it's either that or `invalid memory address or nil pointer dereference` if it's const or var "a" then mainly `unexpected fault address`, but sometime `hashmap assert' if it's const or var "scaf", sometimes it hangs and sometimes it throws `hashmap assert` - other '4-words' behave differently (id ~< "naaa" behaves like "a", id ~> "naaa" behaves like "scaf" - not exhaustively confirmed for all values) The common thing is that the throw or hang always happens as i == 81. Removing the integer or the string field results in normal behaviour. |
Note that the problem reported in comment 6 became issue #3695, now fixed. |
rsc
added a commit
that referenced
this issue
May 11, 2015
««« backport 98488e2e38ee runtime: handle and test large map values This is from CL 5451105 but was dropped from that CL. See also CL 6137051. The only change compared to 5451105 is to check for h != nil in reflect·mapiterinit; allowing use of nil maps must have happened after that original CL. Fixes #3573. R=golang-dev, dave, r CC=golang-dev https://golang.org/cl/6215078 »»»
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: