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: computed hash value for struct map key ignores some fields #3695

kortschak opened this issue Jun 2, 2012 · 8 comments


Copy link

This is possibly a duplicate of 3573, but is logged since the problem does not appear to
be completely fixed at tip, so it was suggested that I relog.

$ go version
go version weekly.2012-03-27 +d8e47164f8dd

What steps will reproduce the problem?
If possible, include a link to a program on
1. Run one of the variations of the program at:

Variations include changing const id = ... to var id = ... and also changing the values
assigned to id. The struct sp can also be defined as a struct { string int string int }
to the same effect as presented in the linked code.

What is the expected output?
The numbers 0-499 on separate line.

What do you see instead?
The numbers 0-81 on separate lines followed by any of (variable results for any given
1. 'throw: hashmap assert'
when id is const or var "", var or const "a", var ~>
"naaa" (4-words checked only)

2. 'invalid memory address or nil pointer dereference'
when id is var ""

3. 'unexpected fault address'
when id is const or var "a" or ~< "naaa" (4-words checked)

4. no termination with 100% CPU usage.
when id is const or var ~> "naaa" (4-words checked only)

NB 4-words not exhaustively checked.

Which compiler are you using (5g, 6g, 8g, gccgo)?

Which operating system are you using?

Which version are you using?  (run 'go version')
go version weekly.2012-03-27 +d8e47164f8dd

Please provide any additional information below.
Using sf with only the int field or the string field results in normal behaviour.
Copy link

robpike commented Jun 2, 2012

Comment 1:

Labels changed: added priority-soon, removed priority-triage.

Owner changed to @rsc.

Status changed to Accepted.

Copy link

Comment 2:

Copy link

rsc commented Jun 13, 2012

Comment 3:

This issue was closed by revision 51fe544.

Status changed to Fixed.

Copy link

Comment 5 by

This still seem like an issue. I just ran the code linked to in the original report on
"go version devel +026b89723112" as well as 1.0.3 on linux(aws ec2 instance) with the
same result as the original report. Compiler is 6g. When hanging with 100% cpu usage it
also blocks any other goroutines. 
It works on OS X 10.8.2 with the same version as on linux and produces the expected

Copy link

Comment 6:

I am unable to reproduce your results. I tried the following:
- go version devel +a522fb590152, amd64
- go version go1.0.3, i386
- go version devel +b8c822e083cf, i386

Copy link

Comment 7:

@ulf, i cannot reproduce the problem either using the sample code provided by the
original reporter of the issue. Your problem may be different. Could you please try to
produce a small example that demonstrates the issue you are seeing and raise a new issue.

Copy link

Comment 8 by

Sorry, my mistake. Turns out we had some path issues on that specific machine and it
picked up an old go1.0 GOROOT.

Copy link

rsc commented Dec 3, 2012

Comment 9:

Status changed to Retracted.

ghost pushed a commit that referenced this issue May 11, 2015
««« backport c8d163b7930e
runtime: improved continuity in hash computation

Fixes #3695.

R=r, dave, rsc

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

5 participants