runtime: computed hash value for struct map key ignores some fields #3695

Closed
kortschak opened this Issue Jun 2, 2012 · 8 comments

Comments

Projects
None yet
5 participants
Contributor

kortschak commented Jun 2, 2012

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 play.golang.org.
1. Run one of the variations of the program at:
http://play.golang.org/p/wG8AK7AAQl

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
program):
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)?
6g

Which operating system are you using?
Linux

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.
Contributor

robpike commented Jun 2, 2012

Comment 1:

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

Owner changed to @rsc.

Status changed to Accepted.

Contributor

rsc commented Jun 13, 2012

Comment 3:

This issue was closed by revision 51fe544.

Status changed to Fixed.

Comment 5 by ulf@nhumi.com:

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
output.

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
Contributor

davecheney commented Nov 29, 2012

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.

Comment 8 by ulf@nhumi.com:

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

rsc commented Dec 3, 2012

Comment 9:

Status changed to Retracted.

rsc was assigned by kortschak Dec 3, 2012

@ghost ghost pushed a commit that referenced this issue May 11, 2015

@atomsymbol @rsc atomsymbol + rsc [release-branch.go1] runtime: improved continuity in hash computation
««« backport c8d163b7930e
runtime: improved continuity in hash computation

Fixes #3695.

R=r, dave, rsc
CC=golang-dev
https://golang.org/cl/6304062

»»»
96ab6e4

gopherbot locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.